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Capsule  Description 


This  module  presents  an  introduction  to  models  of 
software  system  evolution  and  their  role  in  structur¬ 
ing  software  development  It  includes  a  review  of 
traditional  software  life-cycle  models  as  well  as  soft¬ 
ware  process  models  that  have  been  recently  pro¬ 
posed.  It  identifies  three  kinds  of  alternative  models 
of  software  evolution  that  focus  attention  to  either 
the  products,  production  processes,  or  production 
settings  as  the  major  source  of  influence.  It  ex¬ 
amines  how  different  software  engineering  tools  arid 
techniques  can  support  life-cycle  or  process  ap¬ 
proaches.  It  also  identifies  techniques  for  evaluating 
the  practical  utility  of  a  given  model  of  software 
evolution  for  development  projects  in  different  kinds 
of  organizational  settings. 


Philosophy 


This  module  presents  the  concepts  and  approaches 
for  organizing  software  engineering  activities  over 
the  life  of  software  systems.  As  such,  it  focuses  at¬ 
tention  to: 

•  what  software  life-cycle  models  are  and 
how  they  are  used 

•  what  software  process  models  are  and 
how  they  can  be  used  to  model  the  soft¬ 
ware  life-cycle 

•  traditional  software  life-cycle  models 

•  alternative  software  evolution  models 
centered  around  software  product,  pro¬ 
duction  process,  or  production  setting 
characteristics 

•  how  software  engineering  tools  and  tech¬ 
niques  fit  into  the  models 

•  techniques  for  evaluating  software  evolu¬ 


tion  models  and  methodologies 

•  techniques  for  customizing  software  life- 
cycle  process  models  to  best  suit  individ¬ 
ual  own  needs. 


Objectives 


The  material  covered  by  this  module  seeks  to  convey 
to  students  the  following  objectives: 

•  a  basic  recognition  that  software  systems 
can  be  produced  and  consumed  accord¬ 
ing  to  different  systematic  models  of 
software  evolution 

•  there  are  alternative  ways  to  organize 
software  development  efforts,  and  that 
the  alternatives  can  focus  attention  to 
software  product,  production  process,  or 
production  setting  characteristics 

•  more  attention  is  being  focussed  to 
codifying  models  of  software  evolution 
into  computational  forms  amenable  to 
simulation,  analysis,  and  articulation  of 
schemes  for  integrating  various  software 
engineering  tools  and  techniques 

•  software  evolution  is  itself  a  process  that 
can  be  prototyped,  systematically  devel¬ 
oped,  (re-)configured,  measured,  refined, 
maintained,  and  managed 


Prerequisite  Knowledge 


The  prerequisites  for  this  module  depend  on  the 
level  of  coverage  intended  for  students.  For  a  short 
introduction  to  life-cycle  models  of  three  hours  or 
less,  an  introduction  to  computer  science  and  pro- 
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gramming  is  sufficient  For  a  more  in-depth  treat¬ 
ment  of  traditional  and  alternative  software  life- 
cycle  models  of  15-20  hours,  then  prior  experience 
as  a  participant  in  a  software  development  project  is 
strongly  recommended,  as  is  knowledge  of  computa¬ 
tional  process  models  (e.g.,  state  machines,  aug¬ 
mented  transition  networks,  petri  networks).  For  an 
advanced,  full  course-length  examination  of  soft¬ 
ware  life-cycle  and  process  models,  then  prior  cour- 
seworic  in  software  engineering  and  experience  on  a 
large  software  project  is  strongly  recommended,  as 
is  some  prior  training  or  experience  with  experimen¬ 
tal  research  design  methods. 
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Module  Content 


Outline _ 

I.  Introduction 

1.  Historical  origins  for  system  life-cycle  models 

2.  Software  life-cycle  activities 

3.  What  is  a  software  life-cycle  model? 

4.  How  can  software  life-cycle  models  be  used? 

5.  What  is  a  software  process  model? 

6.  Evolutionistic  vs.  Evolutionary  Models 

7.  The  neglected  activities  of  software  evolution 
n.  Traditional  Software  Life-Cycle  Models 

1.  Classic  Software  Life-Cycle 

2.  Stepwise  Refinement  and  Iterative 
Enhancement 

3.  Incremental  Release 

4.  Industrial  Practices  and  Military  Standards 
HI.  Alternative  Life-Cycle  Models 

1.  Software  Product  Development  Models 

a.  Prototyping 

b.  Assembling  Reusable  Components 

c.  Application  Generation 

d.  Program  Evolution  Models 

2.  Software  Production  Process  Models 

a.  Non- Operational  Process  Models 

b.  Operational  Process  Models 

3.  Software  Production  Setting  Models 

a.  Software  project  management  process 
models 

b.  Organizational  software  development  models 

c.  Customer  resource  life-cycle  models 

d.  Software  technology  transfer  and  transition 
models 

e.  Other  models  for  the  organization  of  system 
production  and  manufacturing 

IV.  Where  do  tools  and  techniques  fit  into  the 
models? 

1.  Life-Cycle  support  mechanisms 

2.  Process  support  mechanisms 

V.  Evaluating  Life-Cycle  Models  and 
Methodologies 

1.  Comparative  evaluation  of  life-cycle  and 


process  methodologies 
2.  Research  problems  and  opportunities 

VI.  Customizable  Life-Cycle  Process  Models 

1.  Selecting  an  Existing  Model 

2.  Customizing  your  own  Model 

3.  Using  Process  Metrics  and  Empirical 
Measurements 

4.  Staffing  the  Life-Cycle  Process  Modeling 
Activity 


Annotated  Outline _ 

I.  Introduction 

Software  evolution  represents  the  cycle  of  activities  in¬ 
volved  in  the  development,  use,  and  maintenance  of 
software  systems.  Software  systems  come  and  go 
through  a  series  of  passages  that  account  for  their  in¬ 
ception,  initial  development,  productive  operation,  up¬ 
keep,  and  retirement  from  one  generation  to  another. 
Material  in  this  section  identifies  the  historical  origins 
of  the  software  life-cycle  concept,  the  general  activities 
included,  the  similarities  and  differences  between  soft¬ 
ware  life-cycle  and  software  process  models,  and  re¬ 
lated  issues.  This  section  is  therefore  appropriate  for  all 
students  of  software  engineering. 

1.  Historical  origins  for  system  life-cycle  models 

Originally,  system  life-cycle  models  emerged  in  the 
fields  of  evolutionary  biology  and  cybernetics.  In 
turn,  models  of  software  evolution  date  back  to  the 
earliest  projects  developing  large  software  systems 
[Benington56,  Hosier61.  Royce70].  Overall,  the  ap¬ 
parent  purpose  of  these  software  life-cycle  models 
was  to  provide  an  abstract  scheme  accounting  for  the 
"natural"  or  engineered  development  of  software 
systems.  Such  a  scheme  could  therefore  serve  as  a 
basis  for  planning,  organizing,  staffing,  coordinat¬ 
ing,  budgeting,  and  directing  software  development 
activities. 

2.  Software  life-cycle  activities 

Fa*  more  than  a  decade,  many  descriptions  of  the 
classic  software  life-cycle  (often  referred  to  as  "the 
waterfall  chart")  have  appeared  (e.g.,  [Royce70, 
Boehm76,  Distaso80,  Scacchi84,  Fairlay85])  and 
have  usually  included  some  version  of  the  following 
activities: 

•  System  Initiation! Adoption:  identifies 
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where  systems  come  from.  In  most  situa¬ 
tions,  new  systems  replace  or  supplement 
existing  processing  mechanisms  whether 
they  were  previously  automated,  manual, 
or  informal 

•  Requirement  Analysis  and  Specification: 
identifies  the  problems  a  new  software 
system  is  supposed  to  solve. 

•  Functional  Specification  or  Prototyping: 
identifies  and  potentially  formalizes  the 
objects  of  computation,  their  attributes  and 
relationships,  the  operations  that  transform 
these  objects,  the  constraints  that  restrict 
system  behavior,  and  so  forth. 

•  Partition  and  Selection  (Build  vs.  Buy  vs. 
Reuse):  given  requirements  and  functional 
specifications,  divides  the  system  into 
managable  pieces  that  denote  logical  sub¬ 
systems,  then  determines  whether  new,  ex¬ 
isting,  or  reusable  software  systems  cor¬ 
respond  to  the  needed  pieces. 

•  Architectural  Configuration  Specification: 
defines  the  interconnection  and  resource 
interfaces  between  system  modules  in 
ways  suitable  for  their  detailed  design  and 
overall  configuration  management 

•  Detailed  Component  Design  Specification: 
defines  the  procedural  methods  through 
which  each  module’s  data  resources  are 
transformed  from  required  inputs  to  pro¬ 
vided  outputs. 

•  Component  Implementation  and 
Debugging:  codifies  the  preceding  speci¬ 
fications  into  operational  source  code  im¬ 
plementations  and  validates  their  basic  op¬ 
eration. 

•  Software  Integration  and  Testing:  affirms 
and  sustains  the  overall  integrity  of  the 
software  system  architectural  configura¬ 
tion  through  verifying  the  consistency  and 
completeness  of  implemented  modules, 
verifying  the  resource  interfaces  and  inter¬ 
connections  against  their  specifications, 
and  validating  the  performance  of  the  sys¬ 
tem  and  subsystems  against  their  require¬ 
ments. 

•  Documentation  Revision  and  System 
Delivery:  packaging  and  rationalizing 
recorded  system  development  description 
into  systematic  documents  and  user 
guides,  all  in  a  form  suitable  for  dissemi¬ 
nation  and  system  support 

•  Training  and  Use:  providing  system  users 
with  instructional  aids  and  guidance  for 
understanding  the  system’s  capabilities 
and  limits  in  order  to  effectively  use  the 
system. 


•  Software  Maintenance:  sustaining  the  use¬ 
ful  operation  of  a  system  in  its  host/target 
environment  by  providing  requested  func¬ 
tional  enhancements,  repairs,  performance 
improvements,  and  conversions. 

3.  What  is  a  software  life-cycle  model? 

A  software  life-cycle  model  is  either  a  descriptive  or 
prescriptive  characterization  of  software  evolution. 
Typically,  it  is  easier  to  articulate  a  prescriptive  life- 
cycle  model  for  how  software  systems  should  be  de¬ 
veloped.  This  is  possible  since  most  such  models 
are  intuitive.  This  means  that  many  software  devel¬ 
opment  details  can  be  ignored,  glossed  over,  or 
generalized.  This,  of  course,  should  raise  concern 
for  the  relative  validity  and  robustness  of  such  life- 
cycle  models  when  developing  different  kinds  of  ap¬ 
plication  systems  in  different  kinds  of  development 
settings.  Descriptive  life-cycle  models,  on  the  other 
hand,  characterize  how  software  systems  are  ac¬ 
tually  developed.  As  such,  they  are  less  common 
and  more  difficult  to  articulate  for  an  obvious 
reason:  one  must  observe  or  collect  data  throughout 
the  development  of  a  software  system,  a  period  of 
elapsed  time  usually  measured  in  years.  Also, 
descriptive  models  are  specific  to  the  systems  ob¬ 
served,  and  only  generalizable  through  systematic 
analysis.  Therefore,  this  suggests  the  prescriptive 
software  life-cycle  models  will  dominate  attention 
until  a  sufficient  base  of  observational  data  is  avail¬ 
able  to  articulate  empirically  grounded  descriptive 
life-cycle  models. 

4.  How  can  software  life-cycle  models  be  used? 

Some  of  the  ways  these  models  can  be  used  include: 

•  as  a  means  to  organize,  plan,  staff,  budget, 
schedule  and  manage  software  project 
work  over  organizational  time,  space,  and 
computing  environments. 

•  as  prescriptive  outlines  for  what  docu¬ 
ments  to  produce  for  delivery  to  client. 

•  as  a  basis  for  determining  what  software 
engineering  tools  and  methodologies  will 
be  most  appropriate  to  support  different 
life-cycle  activities. 

•  as  frameworks  for  analyzing  or  estimating 
patterns  of  resource  allocation  and  con¬ 
sumption  during  the  software  life-cycle 
[Boehm81a]. 

•  as  comparative  descriptive  or  prescriptive 
accounts  for  how  software  systems  come 
to  be  the  way  they  are. 

•  as  a  basis  for  conducting  empirical  studies 
to  determine  what  affects  software  produc¬ 
tivity,  cost,  and  overall  quality. 

5.  What  is  a  software  process  model? 
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A  software  process  model  often  represents  a  net¬ 
worked  sequence  of  activities,  objects,  transfor¬ 
mations,  and  events  that  embody  strategies  for  ac¬ 
complishing  software  evolution  [Potts84,  Wileden86, 
Dowson86],  Such  models  can  be  used  to  develop 
more  precise  and  formalized  descriptions  of  soft¬ 
ware  life-cycle  activities.  Their  power  emerges 
from  their  use  of  a  sufficiently  rich  notation,  syntax, 
or  semantics,  often  suitable  for  computational  proc¬ 
essing. 

Software  process  networks  can  be  viewed  as 
representing  methodical  task  chains.  Task  chains 
structure  the  transformation  of  computational  en¬ 
tities  through  a  passage  of  sequence  of  actions  that 
denote  each  process  activity.  Task  chains  are 
idealized  plans  of  what  actions  should  be  accom¬ 
plished,  and  in  what  order.  For  example,  a  task 
chain  for  the  activity  of  object-oriented  software  de¬ 
sign  might  include  the  following  task  actions: 

•  Develop  an  informal  narrative  specifica¬ 
tion  of  the  system. 

•  Identify  the  objects  and  their  attributes. 

•  Identify  the  operations  on  the  objects. 

•  Identify  the  interfaces  between  objects,  at¬ 
tributes,  or  operations. 

•  Implement  the  operations. 

Task  chains  join  or  split  into  other  task  chains  result¬ 
ing  in  an  overall  production  lattice.  The  production 
lattice  represents  the  "organizational  system"  that 
transforms  raw  computational,  cognitive,  and  other 
organizational  resources  into  assembled,  integrated 
software  systems.  The  production  lattice  therefore 
represents  the  structure  of  how  a  software  system  is 
developed,  used,  and  maintained.  However,  tasks 
chains  and  actions  are  never  sufficiently  described  to 
anticipate  all  possible  contingencies  or  problems  that 
can  emerge  in  the  real-world  of  software  develop¬ 
ment  Thus  any  software  production  lattice  will  in 
some  way  realize  only  an  approximate  or  incomplete 
description  of  software  development  As  such, 
articulation  work  will  be  performed  when  a  task 
chain  is  inadequate  or  breaks  down.  The  articulation 
work,  then  represents  a  non-deterministic  sequence 
of  actions  taken  to  restore  progress  on  the  disarticu¬ 
lated  task  chain,  or  else  to  shift  the  flow  of  produc¬ 
tive  work  onto  some  other  task  chain  [Bendifallah87]. 

6.  Evolutionistic  vs.  Evolutionary  Models 

Every  model  of  software  evolution  makes  certain  as¬ 
sumptions  about  the  meaning  of  evolution.  In  one 
such  analysis  of  these  assumptions,  two  distinct 
views  are  apparent:  evolutionistic  models  focus  on 
the  direction  of  change  in  terms  of  progress  through 
a  series  of  stages  eventually  leading  to  some  final 
stage;  evolutionary  models,  on  the  other  hand,  focus 
attention  to  the  mechanisms  and  processes  that 
change  systems  [King84],  Evolutionistic  models  are 


often  intuitive  and  useful  as  organizing  frameworks 
for  managing  and  tooling  software  development  ef¬ 
forts.  But  they  are  poor  predictors  of  why  certain 
changes  are  made  to  a  system,  and  why  systems 
evolve  in  similar  or  different  ways  [Bandifallah87]. 
Evolutionary  models  are  concerned  less  with  the 
stage  of  development,  and  more  with  the  techno¬ 
logical  mechanisms  and  organizational  processes 
that  guide  the  emergence  of  a  system  over  space  and 
time.  As  such,  it  should  become  apparent  that  the 
traditional  models  are  evolutionistic,  while  most  of 
the  alternative  models  are  evolutionary. 

7.  The  neglected  activities  of  software  evolution 

Three  activities  critical  to  the  overall  evolution  of 
software  systems  are  maintenance,  technology  trans¬ 
fer,  and  evaluation  However,  these  activities  are  of¬ 
ten  inadequately  addressed  in  most  models  of  soft¬ 
ware  evolution.  Thus,  any  model  of  software  evolu¬ 
tion  should  be  examined  to  see  to  what  extent  it 
addresses  these  activities. 

Software  maintenance  often  seems  to  be  described 
as  just  another  activity  in  the  evolution  of  software. 
However,  many  studies  indicate  that  software  sys¬ 
tems  spend  most  of  their  useful  life  in  this  activity 
[Boehm 76,  BoehmSIa].  A  reasonable  examination 
of  the  activity  indicates  that  maintenance  represents 
ongoing  incremental  iterations  through  the  life-cycle 
activities  that  precede  it  [Basiii75],  These  iterations 
are  an  effective  way  to  incorporate  new  functional 
enhancements,  remove  errors,  restructure  code,  im¬ 
prove  system  performance,  or  convert  a  system  to 
run  in  another  environment  Subsequently,  software 
maintenance  activities  represent  micro-level  pas¬ 
sages  through  the  life-cycle.  However,  it  is  also 
clear  that  many  other  technical  and  organizational 
circumstances  profoundly  shape  the  evolution  of  a 
software  system  and  its  host  environment 
[Lehman86a,  Bendifallah87].  Thus,  every  software 
life-cycle  or  process  model  should  be  closely  ex¬ 
amined  to  see  to  what  extent  its  accounts  for  what 
happens  to  a  software  system  during  most  of  its  sus¬ 
tained  operation. 

Concerns  for  system  installation  and  support  need  to 
be  addressed  during  the  earliest  stages  of  software 
evolution.  These  concerns  eventually  become  the 
basis  for  determining  the  success  or  failure  of  soft¬ 
ware  system  use  and  maintenance  activities.  Early 
and  sustained  involvement  of  users  in  system  devel¬ 
opment  is  one  of  the  most  direct  ways  to  affect  a 
successful  software  technology  transfer.  Failure  to 
involve  users  is  one  of  the  most  common  reasons 
why  system  use  and  maintenance  is  troublesome. 
Thus,  any  model  of  software  evolution  can  be  evalu¬ 
ated  according  to  the  extent  that  it  accommodates 
activities  or  mechanisms  that  encourage  system  de¬ 
velopers  and  users  to  cooperate. 


SEI-CM-1 0-1.0 


Draft  For  Public  Review 


5 


Models  of  Software  Evolution:  Life  Cycle  and  Process 


Evaluating  the  evolution  ot  software  systems  helps 
determine  which  development  activities  or  actions 
could  be  made  more  effective.  Many  models  of  soft¬ 
ware  evolution  do  not  address  how  system  devel¬ 
opers  (or  users)  should  evaluate  their  practices  to 
deter' ine  which  of  their  activities  could  be  im¬ 
proved  or  restructured.  Technical  reviews  and  soft¬ 
ware  inspections  often  focus  attention  to  how  to  im¬ 
prove  the  quality  of  the  software  products  being  de¬ 
veloped,  while  the  organizational  and  technological 
processes  leading  to  these  products  receive  less  at¬ 
tention.  Evaluating  development  activities  also  im¬ 
plies  that  both  the  analytical  skills  and  tools  are 
available  to  a  development  group.  Thus,  models  of 
software  evolution  can  also  be  scrutinized  to  deter¬ 
mine  to  what  extent  they  incorporate  or  structure 
development  activities  in  ways  that  provide  devel¬ 
opers  with  the  means  to  evaluate  the  effectiveness  of 
the  engineering  practices. 

Finally,  one  important  purpose  of  evaluating  local 
practices  for  software  evolution  is  to  identify  oppor¬ 
tunities  where  new  technologies  can  be  inserted.  In 
many  situations,  new  software  engineering  tools, 
techniques,  or  management  strategies  are  introduced 
during  the  middle  of  a  system  development  effort. 
How  do  such  introductions  impact  existing  prac¬ 
tices?  What  consequences  do  such  introductions 
have  on  the  maintainability  of  systems  currently  in 
use  or  in  development?  Software  maintenance,  tech¬ 
nology  transfer,  and  process  evaluation  are  each  cri¬ 
tical  to  the  effective  evolution  of  software  systems, 
as  is  their  effect  on  each  other.  Thus,  they  should  be 
treated  collectively,  and  in  turn,  models  of  software 
evolution  can  be  reviewed  in  terms  of  how  well  they 
address  this  collective. 

II.  Traditional  Software  Life-Cycle  Models 

These  models  of  software  evolution  have  been  with  us 
in  some  cases  since  the  earliest  days  of  software  engi¬ 
neering.  The  classic  software  life-cycle  (or  "waterfall" 
model)  and  stepwise  refinement  are  widely  instantiated 
in  just  about  all  books  on  modern  programming  prac¬ 
tice  and  software  engineering.  The  incremental  release 
model  is  closely  related  to  industrial  practices  where  it 
most  often  occurs.  Military  standards  have  also  reified 
certain  forms  of  the  classic  life-cycle  model  into  re¬ 
quired  practice  for  government  contractors.  Since  of 
these  life-cycle  models  have  been  in  use  for  some  time, 
we  refer  to  them  as  the  traditional  models,  and  identify 
each  below. 

1.  Classic  Software  Life-Cycle 

The  classic  software  life-cycle  is  often  represented 
as  a  simple  waterfall  software  phase  model,  where 
software  evolution  proceeds  through  an  orderly  se¬ 
quence  of  transitions  from  one  phase  to  the  next  in 
linear  order.  Such  models  resemble  finite  state  ma¬ 
chine  descriptions  of  software  evolution.  However, 
such  models  have  been  perhaps  most  useful  in  help¬ 


ing  to  structure  and  manage  large  software  devel¬ 
opment  projects  in  organizational  settings. 

2.  Stepwise  Refinement  and  Iterative 
Enhancement 

This  model  advocates  developing  software  systems 
through  ongoing  refinement  and  enhancement  of 
high-level  system  specifications  into  source  code 
components  [Wirth71,  Basi!i75].  These  models  have 
been  most  effective  in  helping  to  teach  individual 
programmers  how  to  organize  their  software  devel¬ 
opment  work.  Many  interpretations  of  the  classic 
software  life  cycle  subsume  this  approach  within 
their  design  and  implementations. 

3.  Incremental  Release 

This  model  advocates  developing  systems  by  first 
providing  essential  operating  functions,  then  provid¬ 
ing  system  users  with  improved  and  more  capable 
versions  of  a  system  at  regular  intervals  [Tully84]. 
This  model  combines  the  classic  software  life-cycle 
with  iterative  enhancement  at  the  level  of  system 
development  organization.  It  also  provides  a  way  to 
periodically  distribute  software  maintenance  updates 
and  services  to  dispersed  user  communities.  This  in 
turn  accommodates  the  provision  of  standard  soft¬ 
ware  maintenance  contracts.  It  is  therefore  a  popular 
model  of  software  evolution  used  by  commercial 
firms. 

4.  Industrial  Practices  and  Military  Standards 

Industrial  firms  often  adopt  some  variation  of  the 
classic  model  as  the  basis  of  the  software  develop¬ 
ment  practice  [Royce70,  Boehm76,  Distaso80. 
Scacchi84,  Scacchi86a],  Many  government  contrac¬ 
tors  organize  their  activities  according  to  military 
standard  life-cycle  models  such  as  that  embodied  in 
MIL-STD-2167  [MIL-STD-21 67].  Such  standards 
outline  not  only  some  variation  of  the  classic  life- 
cycle  activities,  but  they  also  the  content  of  docu¬ 
ments  required  by  clients  who  procure  either  soft¬ 
ware  systems  or  complex  mechanisms  with  em¬ 
bedded  software  systems.  These  standards  are  also 
intended  to  be  compatible  with  provision  of  software 
quality  assurance,  configuration  management,  and 
independent  verification  and  validation  services  in  a 
multi-contractor  development  project  More  recent 
progress  in  industrial  practice  appears  in 
[Humphrey85,  Radice85,  Yacobellis84], 

III.  Alternative  Life-Cycle  Models 

There  are  at  least  three  alternative  sets  of  models  of 
software  evolution.  These  models  are  alternatives  to 
the  traditional  software  life-cycle  models.  These  three 
sets  focus  attention  on  either  the  products,  production 
processes,  or  production  settings  associated  with  soft¬ 
ware  evolution.  Since  these  models  are  not  in  wide¬ 
spread  practice,  discussion  of  them  is  appropriate  at  an 
intermediate  level  of  coursework,  while  in-depth  re- 
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view  is  appropriate  at  an  advanced  level.  However,  all 
students  of  software  engineering  should  have  an  over¬ 
view  of  models  of  program  evolution  and  software 
technology  transfer. 

1.  Software  Product  Development  Models 

Software  product  development  models  represent  an 
evolutionary  extension  to  the  traditional  software 
life-cycle  models.  The  extensions  arose  due  to  the 
availability  of  new  software  development  technol¬ 
ogies  such  as  software  prototyping  languages  and 
environments,  reusable  software,  and  application 
generators.  Each  of  these  technologies  seeks  to  en¬ 
able  the  creation  of  executable  software  implemen¬ 
tations  either  earlier  in  the  life-cycle,  or  more 
rapidly  but  with  reduced  functionality.  Discussion  of 
these  models  is  most  appropriate  when  such  technol¬ 
ogies  are  available  for  use  or  experimentation. 

a.  Prototyping 

Prototyping  is  a  technique  for  providing  a  reduced 
functionality  version  of  a  software  system  early  in 
its  development  [8alzar82,  Boehm84,  Budde84, 
Hekmatpour87],  Prototyping  technologies  usually 
accept  some  form  of  software  functional  specifi¬ 
cations  as  input,  which  in  turn  are  either  simu¬ 
lated,  analyzed,  or  directly  executed.  As  such, 
these  technologies  allow  software  design  activi¬ 
ties  to  be  initially  skipped  or  glossed  over.  In 
turn,  these  technologies  can  allow  developers  to 
rapidly  construct  early  or  primitive  versions  of 
software  systems  that  users  can  evaluate.  These 
user  evaluations  can  then  be  incorporated  as  feed¬ 
back  to  refine  the  emerging  system  specifications 
and  designs.  Further,  depending  on  the  prototyp¬ 
ing  technology,  the  complete  working  system  can 
be  developed  through  a  continually  process  of 
revising/refining  the  input  specifications.  This 
has  the  advantage  of  always  providing  a  working 
version  of  the  developing  system,  while  redefin¬ 
ing  software  design  and  testing  activities  to  input 
specification  refinement  and  execution.  Alter¬ 
natively,  other  prototyping  approaches  are  best 
suited  for  developing  "throwaway" 
(demonstration  only)  systems,  or  for  building 
prototypes  by  reusing  part/all  of  some  existing 
software  systems.  Two  collections  of  papers  on 
the  subject  can  be  found  in  [Sen82,  Budde84). 

b.  Assembling  Reusable  Components 

The  basic  approach  of  reusablity  is  to  configure 
and  specialize  pre-existing  software  components 
into  viable  application  systems  [Biggerstaff84, 
Neighbors84,  Goguen86],  However,  the 
granularity  of  the  components  (i.e.,  size,  com¬ 
plexity,  functional  capability)  vary  greatly  across 
different  approaches.  Most  approaches  attempt  to 
utilize  components  similar  to  common  data  struc¬ 
tures  with  algorithms  for  their  manipulation: 


small-grain  components.  However,  the  use/reuse 
of  small-grain  components  in  and  of  themselves 
does  not  constitute  a  distinct  approach  to  software 
evolution.  Other  approaches  attempt  to  utilize 
components  resembling  functionally  complete 
systems  or  subsystems  (e.g.,  user  interface  man¬ 
agement  system):  large-grain  components.  The 
use/reuse  of  large-grain  components  does  appear 
to  be  an  alternative  approach  to  developing  soft¬ 
ware  systems,  and  thus  is  an  area  of  active  re¬ 
search.  There  are  probably  many  ways  to  utilize 
reusable  software  components  in  evolving  soft¬ 
ware  systems.  However,  cited  studies  suggest 
their  initial  use  during  architectural  or  component 
design  specification  as  a  way  to  speed  implemen¬ 
tation.  They  might  also  be  used  for  prototyping 
purposes  if  a  suitable  software  prototyping  tech¬ 
nology  is  available. 

c.  Application  Generation 

Application  generation  is  an  approach  to  software 
development  similar  to  reuse  of  parameterized, 
large-grain  software  components.  Such  compo¬ 
nents  are  spiecialized  to  an  application  domain  via 
a  formalized  specification  language  used  as  input 
to  the  application  generator.  Common  examples 
provide  standardized  interfaces  to  database  man¬ 
agement  system  applications,  and  include 
generators  for  reports,  graphics,  user  interfaces, 
and  application-specific  editors.  Application 
generators  give  rise  to  a  model  of  software  evolu¬ 
tion  whereby  software  design  activities  are  either 
almost  eliminated,  or  reduced  to  a  database  de¬ 
sign  problem.  Similarly,  users  of  application 
generators  are  usually  expected  to  provide  input 
specifications  and  application  maintenance  ser¬ 
vices.  These  capabilities  are  possible  since  the 
generators  can  usually  only  produce  software  sys¬ 
tems  specific  to  a  small  number  of  similar  appli¬ 
cation  domains,  and  usually  those  that  depend  on 
a  database  management  system  [Horowitz85]. 

d.  Program  Evolution  Models 

In  contrast  to  the  preceding  three  models,  Lehman 
and  Belady  sought  to  develop  a  descriptive  model 
of  software  product  evolution.  They  conducted  a 
series  of  studies  of  the  evolution  of  large  software 
systems  at  IBM  during  the  1970’s  [Lehman85], 
Based  on  their  investigations,  they  identify  five 
properties  that  characterize  the  evolution  of  large 
software  systems.  These  are: 

1 .  Continuing  change :  a  large  software 
system  undergoes  continuing  change 
or  becomes  progressively  less  useful 

2.  Increasing  complexity:  as  a  software 
system  evolves,  its  complexity  in¬ 
creases  unless  work  is  done  to  main¬ 
tain  or  reduce  it 
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3.  Fundamental  law  of  program 
evolution :  program  evolution,  pro¬ 
gramming  process,  and  global  meas¬ 
ures  of  project  and  system  attributes 
are  statistically  self-regulating  with 
determinable  trends  and  invariances 

4.  Invariant  work  rate :  the  rate  of  global 
activity  in  a  large  software  project  is 
statistically  invariant 

5.  Incremental  growth  limit  during  the 
active  life  of  a  large  program,  the  vol¬ 
ume  of  modifications  made  to  succes¬ 
sive  releases  is  statistically  invariant 

However,  it  is  important  to  observe  that  these  are 
global  properties  of  large  software  systems,  not 
causal  mechanisms  of  software  evolution. 

2.  Software  Production  Process  Models 

There  are  two  kinds  of  software  production  process 
models:  non-operational  and  operational.  Both  are 
software  process  models.  The  difference  between 
the  two  primarily  stems  from  the  fact  that  the  opera¬ 
tional  models  can  be  viewed  as  programs:  programs 
that  implement  a  particular  regimen  of  software  en¬ 
gineering  and  evolution.  Non-operational  models,  on 
the  other  hand,  denote  conceptual  approaches  that 
have  not  yet  been  sufficiently  articulated  in  a  form 
suitable  for  codification. 

a.  Non-Operational  Process  Models 

(i)  The  Spiral  Model 

The  spiral  model  of  software  development  and 
evolution  represents  a  risk-driven  approach  to 
software  process  analysis  and  structuring 
[Boehm86].  The  approach  incorporates  ele¬ 
ments  of  specification-driven  and  prototype- 
driven  process  methods.  It  does  so  by 
representing  iterative  development  cycles  in  a 
spiral  manner,  with  inner  cycles  denoting  early 
analysis  and  prototyping,  and  outer  cycles 
denoting  the  classic  system  life-cycle.  The 
radial  dimension  denotes  cumulative  develop¬ 
ment  costs,  and  the  angular  dimension  denotes 
progress  made  in  accomplishing  each  develop¬ 
ment  spiral.  Risk  analysis,  which  seeks  to  iden¬ 
tify  situations  which  might  cause  a  develop¬ 
ment  effort  to  fail  or  go  over  budget/schedule, 
occurs  during  each  spiral  cycle.  In  each  cycle, 
risk  analysis  represents  roughly  the  same 
amount  of  angular  displacement,  while  the  dis¬ 
placed  sweep  volume  denotes  increasing  levels 
of  effort  required  for  risk  analysis.  System  de¬ 
velopment  in  this  model  therefore  spirals  out 
only  so  far  as  needed  according  to  the  risk  that 
must  be  managed. 

(ii)  Continuous  Transformation  Models 
These  models  propose  a  process  whereby  soft¬ 


ware  systems  are  developed  through  an  on¬ 
going  series  of  transformations  of  problem 
statements  into  abstract  specifications  into  con¬ 
crete  implementations  [Wirth71,  Basili75, 
Bauer76,  BalzarSI].  Lehman,  Stenning,  and 
Turski,  for  example,  propose  a  scheme 
whereby  there  is  no  traditional  life-cycle  nor 
separate  stages,  but  instead  an  ongoing  series 
of  reifying  transformations  of  abstract  specifi¬ 
cations  into  more  concrete  programs 
[Lehman84a,  Lehman84b],  In  this  sense  then, 
problem  statements  and  software  systems  can 
emerge  somewhat  together,  and  thus  can  con¬ 
tinue  to  co-evolve. 

Continuous  transformation  models  also  accom¬ 
modate  the  interests  of  software  formalists  who 
seek  the  precise  statement  of  formal  properties 
of  software  system  specifications.  Accord¬ 
ingly,  the  specified  formalisms  can  be  math¬ 
ematically  transformed  into  properties  that  a 
source  implementation  should  satisfy.  The  po¬ 
tential  for  automating  such  models  is  apparent, 
but  it  still  the  subject  of  ongoing  research  (and 
addressed  below). 

(iii)  Miscellaneous  Process  Models 

Many  variations  of  the  non-operational  life- 
cycle  and  process  models  have  been  proposed, 
and  appear  in  the  proceedings  of  the  three  soft¬ 
ware  process  workshops  [Potts84,  Wileden86, 
Dowson86].  These  include  fully  interconnected 
life-cycle  models  which  accommodate  transi¬ 
tions  between  any  two  phases  subject  to  satis¬ 
faction  of  their  pre-  and  post-conditions,  as 
well  as  compound  variations  on  the  traditional 
life  cycle  and  continuous  transformation 
models.  However,  the  cited  repeats  generally 
indicate  that  in  general  most  software  process 
models  are  analytical  or  theoretical,  so  little  ex¬ 
perience  with  these  models  has  been  reported. 

b.  Operational  Process  Models 

(i)  Operational  specifications  for  rapid 
prototyping 

The  operational  approach  to  software  develop¬ 
ment  assumes  the  existence  of  a  formal  specifi¬ 
cation  language  and  processing  environment 
[Bauer76,  Balzer82,  Balzer83a,  Zave84],  Spec¬ 
ifications  in  the  language  are  "coded"  and 
when  possible  constitute  a  functional  prototype 
of  the  specified  system.  When  such  specifica¬ 
tions  can  be  developed  and  processed  in¬ 
crementally,  then  the  resulting  system 
prototypes  can  be  refined  and  evolved  into 
functionally  more  complete  systems,  and  are 
always  operational  during  their  development 
Variations  within  this  approach  represent  either 
efforts  where  the  prototype  is  the  end  sought. 
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or  where  specified  prototypes  are  kept  opera¬ 
tional  but  refined  into  a  complete  system. 

(ii)  Software  process  automation  and 
programming 

Process  automation  and  programming  are  con¬ 
cerned  with  developing  "formal"  specifications 
of  how  a  (family  of)  software  system(s)  should 
be  developed.  Such  specifications  therefore 
should  provide  an  account  for  an  organization 
and  description  of  the  various  software  produc¬ 
tion  task  chains,  how  they  interrelate,  when 
then  can  iterate,  etc.  as  well  as  what  software 
tools  to  use  to  support  different  tasks,  and  how 
these  tools  should  be  used  [Hoffnagel85, 
Huseth86,  Osterweil87],  See  [Lehman87]  and 
[Curtis87]  for  provocative  reviews  of  the  poten¬ 
tial  and  limitations  of  current  proposals  for 
software  process  automation  and  programming. 

(iii)  Knowledge-based  software  automation 

This  model  attempts  to  take  process  automa¬ 
tion  to  its  limits  by  assuming  that  process  spec¬ 
ifications  can  be  used  directly  to  develop  soft¬ 
ware  systems,  and  to  configure  development 
environments  to  support  the  production  tasks  at 
hand.  The  common  approach  is  to  seek  to  auto¬ 
mate  the  continuous  transformation  model  In 
turn,  this  implies  an  automated  environment 
capable  of  recording  the  formalized  develop¬ 
ment  of  operational  specifications,  successively 
transforming  and  refining  these  specifications 
into  an  implemented  system,  assimilating 
maintenance  requests  by  inserting  the 
new/enhanced  specifications  into  the  current 
development  derivation,  then  replaying  the 
revised  development  toward  implementation 
[Bauer76,  Balzer83b,  Balzer85].  However,  cur¬ 
rent  progress  has  been  limited  to  demonstrating 
such  mechanisms  and  specifications  to 
narrowly-defined  software  coding,  mainte¬ 
nance,  project  communication  and  manage¬ 
ment  tasks  [Balzer83b,  Balzer85,  Cheatham  86, 
Polak86,  Kadzierski84,  Sathi85,  Sathi86], 

3.  Software  Production  Setting  Models 

In  contrast  to  product  or  production  process  models 
of  software  evolution,  production  setting  models 
draw  attention  to  organizational  and  management 
strategies  for  developing  and  evolving  software  sys¬ 
tems.  With  rare  exception,  such  models  are  non- 
operational.  As  such,  the  focus  is  less  technological 
and  more  strategic.  But  it  should  become  clear  that 
such  strategies  do  affect  what  software  products  get 
developed  and  how  software  production  processes 
will  be  organized. 

Also,  note  that  the  last  entry  in  this  section  on  other 
models  of  system  production  and  manufacturing  is 


marked  optional,  and  thus  is  perhaps  most  appro¬ 
priate  at  an  advanced  level. 

a.  Software  project  management  process 
models 

In  parallel  to  (or  on  top  of)  a  software  develop¬ 
ment  effort,  there  is  normally  a  management  su¬ 
perstructure  to  configure  the  effort  This  structure 
also  represents  a  cycle  of  activities  for  which 
project  managers  assume  the  responsibility.  The 
activities  include  project  planning,  budgeting  and 
controlling  resources,  staffing,  dividing  and  coor¬ 
dinating  staff,  scheduling  deliverables,  directing 
and  evaluating  (measuring)  progress,  and  inter¬ 
vening  to  resolve  conflicts,  breakdowns,  or 
resource  distribution  anomalies  [ThayerSI, 
Scacchi84,  Kedzierski84,  Radice85, 

Humphrey85]. 

b.  Organizational  software  development  models 

Software  development  projects  are  plagued  with 
many  recurring  organizational  dilemmas  which 
can  slow  progress.  Experienced  managers  recog¬ 
nize  these  dilemmas  and  develop  strategies  for 
mitigating  or  resolving  their  adverse  effects.  Such 
strategies  therefore  form  an  informal  model  for 
how  to  manage  software  development  throughout 
its  life-cycle.  See  [Kling80,  Kidder81,  Kling82, 
Scacchi84,  Gasser86,  Curtis87]  as  well  as 
[Liker86]. 

c.  Customer  resource  life-cycle  models 

With  the  help  of  information  (i.e.,  software)  sys¬ 
tems,  a  company  can  become  more  competitive  in 
all  phases  of  its  customer  relationships  [Ives84, 
Wiseman85].  The  customer  resource  life-cycle 
(CRLC)  model  is  claimed  to  make  it  possible  for 
such  companies  to  determine  when  opportunities 
exist  for  strategic  applications.  Such  applications 
change  a  firm’s  product  line  or  the  way  a  firm 
competes  in  its  industry.  The  CRLC  model  also 
indicates  what  specific  application  systems  should 
be  developed. 

The  CRLC  model  is  based  on  the  following 
premises:  the  products  that  an  organization  pro¬ 
vides  to  its  customers  are,  from  the  customer’s 
viewpoint,  supporting  resources.  A  customer  then 
goes  through  a  cycle  of  resource  definition,  adop¬ 
tion,  implementation  and  use.  This  can  require  a 
substantial  investment  in  time,  effort,  and  man¬ 
agement  attention.  But  if  the  supplier  organization 
can  assist  the  customer  in  managing  this  resource 
life-cycle,  the  supplier  may  then  be  able  to  dif¬ 
ferentiate  itself  from  its  competitors  via  enhanced 
customer  service  or  direct  cost  savings.  Thus,  the 
supplier  organization  should  seek  to  develop  and 
apply  software  systems  that  support  the 
customer's  resource  life-cycle.  [Ives84]  and 
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[Wiseman85]  describe  two  approaches  for  ar¬ 
ticulating  CRLC  models  and  identifying  strategic 
software  system  applications  to  support  them. 

The  purpose  of  examining  such  models  is  to  ob¬ 
serve  that  forces  and  opportunities  in  a 
marketplace  such  as  customer  relationships,  cor¬ 
porate  strategy,  and  competitive  advantage  can 
help  determine  the  evolution  of  certain  kinds  of 
software  systems. 

<L  Software  technology  transfer  and  transition 
models 

The  software  innovation  life-cycle  circumscribes 
the  technological  and  organizational  passage  of 
software  system  technologies.  This  life-cycle 
therefore  includes  the  activities  that  represent  the 
transfer  and  transition  of  a  software  system  from 
its  producers  to  its  consumers.  This  life-cycle 
includes  the  following  activities  [Redwine85, 
Scacchi86b]: 

•  Invention  and  prototyping :  software  re¬ 
search  and  exploratory  prototyping 

•  Product  development  the  software  de¬ 
velopment  life-cycle 

•  Diffusion :  packaging  and  marketing 
systems  in  a  form  suitable  for  wide¬ 
spread  dissemination  and  use 

•  Adoption  and  Acquisition, :  deciding  to 
commit  organizational  resources  to  get 
new  systems  installed 

•  Implementation :  actions  performed  to 
assimilate  newly  acquired  systems  into 
existing  work  and  computing  arrange¬ 
ments 

•  Routinization:  using  implemented  sys¬ 
tems  in  ways  that  seem  inevitable  and 
part  of  standard  procedures 

•  Evolution:  sustaining  the  equilibrium  of 
routine  use  for  systems  embedded  in 
community  of  organizational  settings 
through  enhancements,  restructuring, 
debugging,  conversions,  and  replace¬ 
ments  with  newer  systems. 

Available  research  indicates  that  progress  through 
the  software  innovation  life-cycle  can  take  7-20 
years  for  major  software  technologies  (e.g.,  Unix, 
expert  systems,  programming  environments,  Ada) 
[Redwine85].  Thus,  moving  a  software  develop¬ 
ment  organization  to  a  new  technology  can  take  a 
long  time  and  great  effort  Research  also  indicates 
that  most  software  innovations  (small  or  large) 
fail  to  get  properly  implemented,  and  thus  result 
in  wasted  effort  and  resources  [Scacchi86b].  The 
failure  here  is  generally  not  technical,  but  instead 
primarily  organizational.  Thus,  organizational  cir¬ 
cumstances  and  the  people  who  animate  them 


have  far  greater  affect  in  determining  the  success¬ 
ful  use  and  evolution  of  a  software  innovation, 
than  the  innovation’s  technical  merit  However, 
software  technology  transfer  is  an  area  requiring 
much  more  research. 

e.  Other  models  for  the  organization  of  system 
production  and  manufacturing 

(This  section  is  optional.)  What  other  kinds  of 
models  of  software  production  might  be  possible? 
If  we  look  to  see  how  other  technological  systems 
are  developed,  we  find  tire  following  sort  of 
models  for  system  production: 

•  Ad-hoc  problem  solving,  tinkering,  and 
articulation  wort,  the  weakest  model 
of  production  is  when  people  approach 
a  development  effort  with  little  or  no 
preparation  or  task  chain  plan  at  hand, 
and  thus  rely  solely  upon  their  skill,  ad 
hoc  tools,  or  the  loosely  coordinated  ef¬ 
forts  of  others  get  them  through.  It  is 
situation  specific,  and  driven  by  accom¬ 
modations  to  local  circumstances.  It  is 
therefore  perhaps  the  most  widely  prac¬ 
ticed  form  of  production  and  system 
evolution. 

•  Group  project  software  life-cycle  and 
process  efforts  are  usually  realized  one 
at  a  time,  with  every  system  being 
treated  somewhat  uniquely.  Thus  such 
efforts  are  often  organized  as  group 
projects. 

•  Custom  job  shop:  job  shops  take  on 
only  particular  kinds  of  group  project 
work,  due  to  more  substantial  invest¬ 
ment  in  tooling  and  production 
skill/technique  refinement. 

•  Batched  production:  provides  the  cus¬ 
tomization  of  job  shops  but  for  a  larger 
production  volume.  Subsystems  in  de¬ 
velopment  are  configured  on  jigs  that 
can  either  be  brought  to  workers  and 
production  tools,  or  that  tools  and 
workers  can  be  brought  to  the 
workpieces  or  subsystems. 

•  Pipeline:  when  system  development  re¬ 
quires  the  customization  of  job  shops  or 
the  specialization  of  volume  of  batdred 
production,  while  at  the  same  time  al¬ 
lowing  for  concurrent  development  se¬ 
quences  of  subsystems. 

•  Flexible  manufacturing  systems:  seek  to 
provide  the  customization  capabilities 
of  job  shops,  while  relying  upon  ad¬ 
vanced  automation  to  allow  economies 
of  scale,  task  standardization,  and 
delivery  of  workpieces  of  transfers  lines 
realized  through  rapidly  reconfigurable 
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workstation  tooting  and  process  pro¬ 
gramming.  Recent  proposals  for 
"software  factories”  have  adopted  a  var¬ 
iation  of  this  model  [Scacchi87]. 

•  Transfer  (assembly)  lines:  when  raw  in¬ 
put  resources  or  semi-finished  sub¬ 
assemblies  can  be  moved  through  a  net¬ 
work  of  single  action  workcells,  then 
transfer  tines  are  appropriate. 

•  Continuous  process  control:  when  the 
rate  or  volume  of  uniform  raw  input 
resources  and  finished  output  products 
can  be  made  continuous  and  automat¬ 
ically  variable,  then  a  continuous  proc¬ 
ess  control  form  of  production  is  appro¬ 
priate.  Oil  refining  is  an  example  of 
such  a  process,  with  crude  oil  from 
wells  as  input,  and  petroleum  products 
(gasoline,  kerosene,  multi-grade  motor 
oil)  as  outputs.  Whether  software  can  be 
produced  in  such  a  manner  is  unlikely  at 
this  time. 

IV.  Where  do  tools  and  techniques  fit  into  the 
models? 

Given  the  diversity  of  software  life-cycle  and  process 
models,  where  do  software  engineering  tools  and  tech¬ 
niques  fit  into  the  picture?  This  section  briefly  identi¬ 
fies  some  of  the  places  where  different  software  engi¬ 
neering  technologies  can  be  matched  to  certain  models. 
Another  way  to  look  at  this  section  might  be  to  look 
instead  at  what  software  engineering  technologies 
might  be  available  in  an  individual  setting,  then  seek  a 
model  of  software  evolution  that  is  compatible. 

1.  Life-Cycle  support  mechanisms 

Most  of  the  traditional  life-cycle  models  are  decom¬ 
posed  as  stages.  These  stages  then  provide  bound¬ 
aries  whereby  software  engineering  technologies  are 
targeted.  Thus,  we  find  engineering  techniques  or 
methods  (e.g.,  Yourdon  structured  design,  TRW’s 
software  requirements  engineering  methodology 
(SREM))  being  targeted  to  support  different  life¬ 
cycle  stages,  and  tools  (e.g.,  TRW’s  requirements 
engineering  and  verification  system  (REVS))  tar¬ 
geted  to  support  the  associated  activities.  However, 
there  are  very  few,  if  any,  package  of  tools  and  tech¬ 
niques  that  purport  to  provide  integrated  support  for 
engineering  software  systems  throughout  their  life- 
cycle  [Scacchi87].  Perhaps  this  is  a  shortcoming  of 
the  traditional  models,  perhaps  indicative  that  the 
integration  required  is  too  substantial  to  justify  its 
expected  costs  or  benefits,  or  prehaps  the  necessary 
technology  is  still  in  its  infancy.  Thus,  at  present, 
we  are  more  likely  to  find  ad-hoc  or  loose  collec¬ 
tions  of  software  engineering  tools  and  techniques 
that  provide  partial  support  for  software  life-cycle 
engineering. 


2.  Process  support  mechanisms 

There  are  at  least  three  kinds  of  software  process 
support  mechanisms: 

•  Process  articulation  technologies  denote 
the  prototyping,  reusable  software,  and  ap¬ 
plication  generator  languages  and  environ¬ 
ments  for  rapidly  developing  new  software 
systems. 

•  Process  measurement  and  analysis 
technologies  denote  the  questionnaire,  sur¬ 
vey,  or  performance  monitoring  instru¬ 
ments  used  to  collect  quantifiable  data  on 
the  evolving  characteristics  of  software 
products  and  processes.  Collected  data  can 
in  turn  be  analyzed  with  statistical  tools  to 
determine  descriptive  and  inferential 
relationships  within  the  data.  These 
relationships  can  then  be  interpreted  as  in¬ 
dicators  for  where  to  make  changes  in  cur¬ 
rent  practices  through  a  restructuring  of 
work/resources,  or  through  the  introduc¬ 
tion  of  new  software  engineering  technol¬ 
ogies.  Such  measurement  and  analysis 
technologies  can  therefore  accommodate 
process  refinements  that  improve  its  over¬ 
all  performance  and  product  quality. 

•  Computational  process  models  denote  for¬ 
malized  descriptions  of  software  develop¬ 
ment  activities  in  a  form  suitable  for  auto¬ 
mated  processing.  Such  models  are  envi¬ 
sioned  to  eventually  be  strongly  coupled  to 
available  software  engineering  tools  and 
techniques  in  ways  that  allow  their  config¬ 
uration  and  use  to  be  programmed.  How¬ 
ever,  at  present,  such  models  serve  to  help 
articulate  more  precise  descriptions  for 
how  to  conduct  different  software  engi¬ 
neering  activities. 

V.  Evaluating  Life-Cycle  Models  and 
Methodologies 

Given  the  diversity  of  software  life-cycle  and  process 
models,  how  do  we  decide  which  if  any  is  best,  or 
should  be  the  one  to  follow?  Answering  this  question 
requires  further  research.  Therefore,  material  in  this 
section  is  perhaps  most  appropriate  at  an  advanced 
level. 

1.  Comparative  evaluation  of  life-cycle  and 
process  methodologies 

As  noted  in  Section  I,  descriptive  life-cycle  models 
require  the  empirical  study  of  software  evolution 
products  and  processes.  Therefore,  how  should  such 
a  study  be  designed  to  realize  useful,  generalizable 
results? 

Basically,  empirical  studies  of  actual  software  life- 
cycles  or  processes  should  ultimately  lead  to  models 
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of  evolution  with  testable  predictions  [Curtis80, 
Basili86],  Such  models  in  turn  must  therefore  be  ap¬ 
plicable  across  different  sets  of  comparable  data. 
This  means  that  such  studies  must  use  measurements 
that  are  reliable,  valid,  and  stable.  Reliability  refers 
to  the  extent  that  the  measures  are  accurate  and 
repeatable.  Validity  indicates  whether  the  measured 
values  of  process  variables  are  in  fact  correct  Stabil¬ 
ity  denotes  that  the  instrument  measures  one  or  more 
process  variables  in  a  consistent  manner  across  dif¬ 
ferent  data  sets  [CurtisSO]. 

However,  most  statistical  instruments  are  geared  for 
snapshot  studies  where  certain  variables  can  be  con¬ 
trolled,  while  others  are  independent  Lehman  and 
Belady  use  such  instruments  in  their  evaluation  of 
large  software  system  attributes  [Lehman85],  Their 
study  uses  data  collected  over  periodic  intervals  for 
a  sample  of  large  software  systems  over  a  number  of 
years.  However,  their  results  only  make  strong 
predictions  about  global  program  evolution 
dynamics.  That  is,  they  cannot  predict  what  will 
happen  at  different  life-cycle  stages,  in  different  cir¬ 
cumstances,  or  for  different  kinds  of  software  sys¬ 
tems.  To  make  such  predictions  requires  a  different 
kind  of  study. 

[vandenBosch82]  and  [Curtis87]  propose  two  alter¬ 
native  approaches  to  studying  software  evolution. 
Both  rely  upon  long-term  field  studies  of  a  sample 
of  software  efforts  in  different  organizational  set¬ 
tings.  Their  approach  is  targeted  to  constructing  a 
framework  for  discovering  the  mechanisms  and  or¬ 
ganizational  processes  that  shape  software  evolution 
with  a  comparative  study  sample.  The  generality  of 
the  results  they  derive  can  thus  be  assessed  in  terms 
of  their  sample  space. 

[Kelty87]  provides  an  informing  comparative  anal¬ 
ysis  of  four  methods  for  the  design  of  real-time  soft¬ 
ware  systems.  Although  his  investigation  does  not 
compare  models  of  software  evolution,  his 
framework  is  suggestive  of  what  might  be  accom¬ 
plished  through  comparative  analysis  of  such 
models. 

Other  approaches  that  report  on  the  comparative 
analysis  of  software  evolution  activities  and  out¬ 
comes  can  be  found  elsewhere  [KlingSO,  BasiliSi , 
BoehmSIb]. 

2.  Research  problems  and  opportunities 

As  should  be  apparent,  most  of  the  alternative 
models  of  software  evolution  are  relatively  new,  and 
in  need  of  improvement  and  empirical  grounding.  It 
should  however  also  be  clear  that  such  matters  re¬ 
quire  research  investigations.  Prescriptive  models 
can  be  easy  to  come  by,  whereas  descriptive  models 
require  systematic  research  regimens  which  can  be 
costly.  Nonetheless,  there  are  many  opportunities  to 
further  develop,  combine,  or  refute  any  of  the  alter¬ 


native  models  of  software  evolution.  Comparative 
research  design  methods,  data  sampling,  collection, 
and  analysis  are  all  critical  topics  that  require  careful 
articulation  and  scrutiny  [Basili86],  And  each  of  the 
alternative  models,  whether  focusing  attention  to  ei¬ 
ther  software  products,  production  processes,  pro¬ 
duction  settings,  or  their  combination  can  ideally 
draw  upon  descriptive  studies  as  the  basis  of  their 
prescriptions.  Thus,  we  are  at  a  point  where  empiri¬ 
cal  studies  of  software  life-cycle  or  process  models 
(or  their  components)  are  needed,  and  likely  to  be 
very  influential  if  performed  systematically  and 
rigorously. 

Therefore,  for  advanced  level  students,  it  is  appro¬ 
priate  to  devote  some  attention  to  the  problem  of 
designing  a  set  of  experiments  intended  to  substan¬ 
tiate  or  refute  a  model  of  software  evolution,  where 
critical  attention  should  then  be  devoted  to  evalu¬ 
ating  the  quality  and  practicality  (i.e.,  time,  effort, 
and  resources  required)  of  the  proposed  research. 

VI.  Customizable  Life-Cycle  Process  Models 

Given  the  emerging  plethora  of  models  of  software 
evolution,  how  does  one  choose  which  model  to  put 
into  practice?  This  will  be  a  recurring  question  in  the 
absence  of  empirical  support  for  the  value  of  one 
model  over  others.  We  can  choose  whether  to  select  an 
existing  model,  or  else  to  develop  a  custom  model. 
Either  way,  the  purpose  of  having  a  model  is  to  use  it 
to  organize  software  development  efforts  in  a  more  ef¬ 
fective,  more  productive  way.  But  this  is  not  a  one- 
shot  undertaking.  Instead,  a  model  of  software  evolu¬ 
tion  is  likely  to  be  most  informing  when  not  only  used 
to  prescribe  software  development  organization,  but 
also  when  used  to  continually  measure,  tune,  and  refine 
the  organization  to  be  more  productive,  risk-reducing, 
and  quality  driven  [Humphrey85,  Radice85,  Basili87], 

1.  Selecting  an  Existing  Model 

Choosing  the  one  that’s  right  for  an  individual  soft¬ 
ware  project  and  organization  is  the  basic  concern. 
At  this  time,  we  can  make  no  specific  recommen¬ 
dation  for  which  model  is  best  in  different  cir¬ 
cumstances.  The  choice  is  therefore  open-ended. 
However,  we  might  expect  to  see  the  following 
kinds  of  choices  being  made  with  respect  to  existing 
models:  Generally,  most  software  development  or¬ 
ganizations  are  likely  to  adopt  one  of  the  traditional 
life-cycle  models.  Then  they  will  act  to  customize  it 
to  be  compatible  with  other  organizational  policies, 
procedures,  and  market  conditions.  Software  re¬ 
search  organizations  will  more  likely  adopt  an  alter¬ 
native  model,  since  they  are  likely  to  be  interested  in 
evaluating  the  potential  of  emerging  software  tech¬ 
nologies.  When  development  organizations  adopt 
software  technologies  more  closely  aligned  to  the 
alternative  models  (e.g.,  reusable  components,  rapid 
prototyping),  they  may  try  to  use  them  either  experi¬ 
mentally,  or  to  shoehorn  them  into  a  traditional  life- 
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cycle  model,  with  many  evolutionary  activities  kept 
informal  and  undocumented.  Alternatively,  another 
strategy  to  follow  is  to  do  what  some  similar  organi¬ 
zation  has  done,  and  to  use  the  model  they  employ. 
Studies  published  by  researchers  at  IBM  and  AT&T 
Bell  Laboratories  are  often  influential  in  this  regard 
[Humphrey85,  Radice85,  Yacobellis84], 

2.  Customizing  your  own  Model 

[Basili87]  can  be  recognized  as  one  of  the  foremost 
advocates  for  developing  a  custom  life-cycle  process 
model  for  each  project  and  organization.  Empirical 
studies  of  software  development  seem  to  indicate 
that  life-cycle  process  modeling  will  be  most  effec¬ 
tive  and  have  the  greatest  benefit  if  practiced  as  a 
regular  activity.  Process  metrics  and  measurements 
need  to  be  regularly  applied  to  capture  data  on  the 
effectiveness  of  current  process  activities.  As  sug¬ 
gested  above,  it  seems  likely  that  at  this  time,  the 
conservative  strategy  will  be  to  adopt  a  traditional 
life-cycle  model  and  then  seek  to  modify  or  extend  it 
to  accommodate  new  software  product  or  production 
process  technologies.  However,  it  seems  just  as  like¬ 
ly  that  software  development  efforts  that  adopt  soft¬ 
ware  product,  production  process  and  production 
setting  concerns  into  a  comprehensive  model  may 
have  the  greatest  potential  for  realizing  substantial 
improvement  in  software  productivity,  quality,  and 
cost  reduction  [Scacchi86c], 

3.  Using  Process  Metrics  and  Empirical 
Measurements 

One  important  purpose  of  building  or  buying  a  proc¬ 
ess  model  is  to  be  able  to  apply  it  to  current  software 
development  projects  in  order  to  improve  their 
productivity,  quality,  and  cost-effectiveness 
[Humphrey85,  Radice85].  The  models  therefore  pro¬ 
vide  a  basis  for  instrumenting  the  software  process 
in  ways  that  potentially  reveal  where  development 
activities  are  less  effective,  where  resource  bot¬ 
tlenecks  occur,  and  where  management  interventions 
or  new  technologies  could  have  a  beneficial  impact 
[Basili87,  Yacobellis84].  [Scacchi86c]  go  so  far  as  to 
advocate  a  radical  approach  involving  the  applica¬ 
tion  of  knowledge-based  technologies  for  modeling 
and  simulating  software  product,  production  proc¬ 
ess,  and  production  setting  interactions  based  upon 
empirical  data  (i.e.,  knowledge)  acquired  through 
questionnaire  surveys,  staff  interviews,  observations, 
and  online  monitoring  systems.  Such  an  approach  is 
clearly  within  the  realm  of  basic  research,  but  per¬ 
haps  indicative  of  the  interest  in  developing  high- 
potential,  customizable  models  of  software  evolu¬ 
tion. 

4.  Staffing  the  Life-Cycle  Process  Modeling 
Activity 

Ideally,  the  staff  candidate  best  equipped  to  organize 
or  analyze  an  organizational’s  model  of  software 


evolution  is  one  who  has  mastered  the  range  of  ma¬ 
terial  outlined  in  this  curriculum  module.  That  is,  a 
staff  member  who  has  only  had  an  introductory  or 
even  intermediate  level  exposure  to  this  material  is 
not  likely  to  perform  software  life-cycle  or  process 
modeling  competently.  Large  software  development 
organizations  with  dozens,  hundreds,  or  even 
thousands  of  software  developers  are  likely  to  rely 
upon  one  or  more  staff  members  with  a  reasonably 
strong  background  in  local  software  development 
practices  and  experimental  research  skills.  This  sug¬ 
gests  that  such  staff  are  therefore  likely  to  possess 
the  equivalent  of  a  masters  or  doctoral  degree  soft¬ 
ware  engineering  or  experimental  computer  science. 
In  particular,  a  strong  familiarity  with  experimental 
research  methods,  sampling  strategies,  questionnaire 
design,  survey  analysis,  statistical  data  analysis 
packages,  and  emerging  software  technologies  are 
the  appropriate  prerequisites.  Simply  put,  this  is  not 
a  job  for  any  software  engineer,  but  instead  a  job  for 
software  engineer  (or  industrial  engineer)  with  ad¬ 
vanced  training  and  experience  in  experimental  re¬ 
search  tools  and  techniques. 


Glossary 


articulation  work 

a  non-deterministic  series  of  actions  taken  by 
people  in  response  to  foul-ups,  breakdowns, 
mistakes,  resource  bottlenecks,  or  other  un¬ 
expected  circumstances  that  cause  planned  task 
chains  to  disarticulate.  Hacking  together  soft¬ 
ware  kludges  in  response  to  system  glitches  is  a 
frequently  observed  form  of  articulation  work 
that  occurs  during  software  evolution. 

evolutionary  models 

represent  software  evolution  in  teims  that  focus 
attention  to  the  mechanisms  that  give  rise  to 
changes  made  in  a  system.  Such  models  seek  to 
account  for  how  and  why  software  systems 
emerge  the  way  they  do.  Systems  evolve  not  so 
much  according  to  prescriptive  stages,  but  rather 
in  response  to  the  actions  people  take  to  make 
the  system  fit  their  circumstantial  needs.  Thus, 
when  circumstances  change,  people  will  seek 
opportunities  to  change  the  system. 

evolutionist  models 

represent  software  evolution  in  terms  that  focus 
attention  to  the  direction  of  changes  made  to 
systems.  Such  models  seek  to  explain  the  logic 
of  development  typically  in  the  form  of  stages 
the  follow  one  another,  where  each  stage  is  the 
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precursor  for  the  next  one,  and  ultimately  toward 
a  final  state  (e.g.,  classic  waterfall  life  cycle 
model). 

production  lattice 

the  intersecting  network  of  task  chains  that  col¬ 
lectively  denote  die  structure  of  software  devel¬ 
opment  activities. 

software  evolution 

the  collection  of  software  life  cycle  or  process 
activities  that  cause  systems  to  be  produced  and 
consumed. 

software  life  cycle 

a  typical  sequence  of  phased  activities  that  rep¬ 
resent  the  various  stages  of  engineering  through 
which  software  system  pass. 

software  process 

the  network  of  object  states  and  transitional 
events  that  represent  the  production  of  a  soft¬ 
ware  system  in  a  form  suitable  for  computational 
encoding  and  processing. 

task  chain 

a  planned,  possibly  iterative,  sequence  of  actions 
taken  by  people  in  order  to  transform  raw  pro¬ 
duction  resources  into  consumable  product 
resources. 


14 


Draft  For  Public  Review 


SEI-CM-1 0-1.0 


Models  of  Software  Evolution:  Life  Cycle  and  Process 


Teaching  Considerations 


This  module  collects  and  organizes  a  body  of  knowl¬ 
edge  about  software  evolution  for  the  first  time.  The 
material  has  not  been  taught  in  this  form,  and  there¬ 
fore  suggestions  for  effective  teaching  have  not  been 
developed.  However,  prior  experience  in  teaching 
part  of  this  material  suggests  the  use  of  case  studies 
of  large  system  development  projects  as  an  excellent 
source  material  for  study  and  review.  For  an  ad¬ 
vanced  level  course,  a  book  such  as  The  Soul  of  a 
New  Machine  by  Tracy  Kidder  is  an  excellent 
choice.  For  an  intermediate  level  of  coverage,  indi¬ 
vidual  case  studies  provide  suitable  source  material 
that  can  introduce  students  to  the  interrelationship  of 
software  products,  production  processes,  and  pro¬ 
duction  settings  as  sources  of  influence  in  system 
evolution.  A  subsequent  release  of  this  module  will 
include  suggestions  from  instructors  who  have 
taught  the  material. 
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results,  Boehm  indicates  that  personnel/team  capa¬ 
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USC  student  teams  developed  a  small,  interactive 
application  software  product  to  the  same  specifi¬ 
cation,  one  using  Fortran  and  one  using  Pascal. 
Several  hypotheses  were  tested,  and  extensive  ex¬ 
perimental  data  collected.  The  major  conclusions 
were  as  follows. 

•  Large-project  software  engineering  proce¬ 
dures  can  be  cost-effectively  tailored  to 
small  projects. 

• The  choice  of  programming  language  is 
not  the  dominant  factor  in  small  applica¬ 
tion  software  product  development. 

•  Programming  is  not  the  dominant  activity 
in  small  software  product  development. 

•  The  " deadline  effect"  holds  on  small  soft¬ 
ware  projects  and  can  be  used  to  help 
manage  software  development. 


•  Most  of  the  code  in  a  small  application 
software  product  is  devoted  to 
"housekeeping." 

The  paper  presents  the  experimental  data  support¬ 
ing  these  conclusions,  and  discusses  their  context 
and  implications. 
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Abstract:  In  this  experiment,  seven  software  teams 
developed  versions  of  the  same  small-size 
(2000-4000  source  instruction)  application  software 
product.  Four  teams  used  the  Specifying  approach. 
Three  teams  used  the  Prototyping  approach. 

The  main  results  of  the  experiment  were: 

•  Prototyping  yielded  products  with  roughly 
equivalent  performance  but  with  about 
40%  less  code  and  45%  less  effort. 

•  The  prototyped  products  rated  somewhat 
lower  on  functionality  and  robustness,  but 
higher  on  case  of  use  and  ease  of  learning. 

•  Specifying  produced  more  coherent  de¬ 
signs  and  software  that  were  easier  to  inte¬ 
grate. 

The  paper  presents  the  experimental  data  support¬ 
ing  these  and  a  number  of  additional  conclusions. 
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Presents  a  new  model  for  modeling  the  software 
process  that  explicitly  attempts  to  address  how  to 
manage  the  risks  associated  with  the  development 
of  different  kinds  of  software  systems.  The  presen¬ 
tation  of  the  model  is  somewhat  obscure;  however, 
its  focus  on  addressing  risk  as  a  central  component 
in  determining  how  to  structure  the  software  devel¬ 
opment  process  is  unique  and  worth  careful  ex¬ 
amination. 
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York:  Springer- Veriag,  1984. 

Presents  a  collection  of  papers  on  software 
prototyping  originally  presented  at  a  conference  on 
tht  topic  in  Europe  in  1984.  After  [SEN82],  the 
most  extensive  survey  of  approaches  to  software  de¬ 
velopment  and  evolution  through  the  use  of 
prototyping  tools  and  techniques. 
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Cheatham,  T.  “Supporting  the  Software  Process.” 
Proc.  19th.  Hawaii  Intern.  Conf.  Systems  Sciences.  , 
1986,  814-821. 

Describes  a  segment  of  the  radical  approach  to  auto¬ 
mating  software  development  introduced  in 
Balzer83b.  This  segment  addresses  how  to  support 
development  and  debugging  of  software  compo¬ 
nents  through  use  of  task-level  protocols  and  associ¬ 
ated  tools. 

Curtls87 

Curtis,  B.,  H.  Krasner,  V.  Shen,  and  N.  Iscoe.  “On 
Building  Software  Process  Models  Under  the 
Lamppost.”  Proc.  9th.  Intern.  Conf.  Software 
Engineering.  IEEE  Computer  Society,  April  1987, 
96-103. 

Abstract:  Most  software  process  models  are  based 
on  the  management  tracking  and  control  of  a  proj¬ 
ect.  The  popular  alternatives  to  these  models  such 
as  rapid  prototyping  and  program  transformation 
are  built  around  specific  technologies,  many  of 
which  are  still  in  their  adolescence.  Neither  of 
these  approaches  describe  the  actual  processes  that 
occur  during  the  development  of  a  software  system. 
That  is,  these  models  focus  on  the  series  of  artifacts 
that  exist  at  the  end  of  phases  of  the  process,  rather 
than  on  the  actual  processes  that  are  conducted  to 
create  the  artifacts.  We  conducted  a  field  study  of 
large  system  development  projects  to  gather  empiri¬ 
cal  information  about  the  communication  and  tech¬ 
nical  decision-making  process  that  underlie  the  de¬ 
sign  of  such  systems.  The  findings  of  this  study  are 
reviewed  for  their  implications  on  modeling  the 
process  of  designing  large  software  systems.  The 
thesis  of  the  paper  is  that  while  there  are  many  foci 
for  process  models,  the  most  valuable  are  those 
which  capture  the  processes  that  control  the  most 
variance  in  software  productivity  and  quality. 

Curtls80 

Curtis,  B.  “Measurement  and  Experimentation  in 
Software  Engineering.”  Proceedings  IEEE  68,  9 
(1980),  1144-1157. 

Provides  a  survey  of  basic  concerns  that  should  be 
addressed  in  any  systematic  or  experimental  study 
of  software  development  practices. 

Dlstaso80 

Distaso,  J.  “Software  Management  —  A  Survey  of 
Practice  in  1980.”  Proceedings  IEEE  68,  9  (1980), 
1103-1119. 

Provides  a  survey  of  the  general  issues  of  software 
project  management  based  upon  experiences  in 
large  projects  during  the  1970’ s. 


Dowson86 

Proc.  3rd.  Intern.  Software  Process  Workshop, 
M.  Dowson,  ed.  Los  Alamitos,  Calif.:  IEEE  Com¬ 
puter  Society,  1986. 

Proceedings  of  the  most  recent  workshop  on  soft¬ 
ware  process  models.  Presents  short  papers  on  a 
variety  of  different  approaches  to  process  modeling 
including  object-oriented  process  programming. 

Fairley85 

Fairley,  R.  Software  Engineering  Concepts.  New 
Yoric:  McGraw-Hill,  1985. 

One  of  the  best  textbooks  on  software  engineering 
currently  available. 

Gasser86 

Gasser,  L.  “The  Integration  of  Computing  and 
Routine  Work.”  ACM  Trans.  Office  Info.  Sys.  4,  3 
(July  1986),  205-225. 

Describes  the  results  of  an  empirical  study  of  soft¬ 
ware  evolution  practices  in  a  large  manufacturing 
organization.  Gasser  reports  that  software  systems 
regularly  fail  to  be  compatible  with  the  instrumental 
work  activities  they  are  suppose  to  support,  and  that 
a  variety  of  forms  of  "work-arounds"  and  other  ac¬ 
comodations  are  performed  by  users  and  main¬ 
tained  to  deal  with  such  systems.  These  accomoda¬ 
tions  and  negotiations  therefore  play  a  central  role 
in  shaping  the  evolution  of  such  systems. 

Goguen86 

Goguen,  J.  “Reusing  and  Interconnecting  Software 
Components.”  Computer  19, 2  (Feb.  1986),  16-28. 

Abstract:  Realizing  the  considerable  economic  po¬ 
tential  of  software  reuse  requires  new  programming 
environment  ideas.  This  article  presents  a  library 
interconnection  language  featuring  modest  use  of 
semantics. 

Hekmatpour87 

Hekmatpour,  S.  “Experience  with  Evolutionary 
Prototyping  in  a  Large  Software  Project.”  ACM 
Software  Engineering  Notes  12, 1  (1987),  38-41. 

Describes  three  alternative  approaches  to  evolving 
the  development  of  software  systems  through 
prototyping  techniques  and  tools. 

Hoffnagel85 

Hoflnagel,  G.  F.,  and  W.  Beregi.  “Automating  the 
Software  Development  Process.”  IBM  Systems 
J.  24, 2  (1985),  102-120. 

Describes  a  complementary  approach  to  [Radc»85] 
that  introduces  automated  mechanisms  and  tech- 


SEI-CM-1 0-1.0 


Draft  For  Public  Review 


19 


Models  of  Software  Evolution:  Life  Cycle  and  Process 


niques  for -supporting  large-scale  software  produc¬ 
tion  processes. 

Horowitz85 

Horowitz,  E.,  A.  Kemper,  and  B.  Narasimhan.  “A 
Survey  of  Application  Generators.”  IEEE  Software 
2, 1  (Jan.  1985),  40-54. 

As  the  title  suggests,  this  article  provides  a  survey 
of  the  basic  software  mechanisms  and  components 
used  in  many  application  generators.  The  presen¬ 
tation  is  clear  and  succinct,  and  represents  one  of 
the  few  published  descriptions  of  the  increasingly 
important  software  development  technology. 

Hosier6l 

Hosier,  W.  A.  “Pitfalls  and  Safeguards  in  Real-Time 
Digital  Systems  with  Emphasis  on  Programming.” 
IRE  Trans.  Engineering  Management  EM-8  (June 
1961).  (Also  appears  in  Proc.  9th.  Intern.  Corf.  Soft¬ 
ware  Engineering,  31 1-327). 

Abstract:  Real-time  digital  systems  are  largely  a 
technical  innovation  of  the  past  decade,  but  they 
appear  destined  to  become  more  wide  spread  in  the 
future.  They  monitor  or  control  a  real  physical  en¬ 
vironment,  such  as  an  air-traffic  situation,  as  distin¬ 
guished  from  simulating  that  environment  on  an  ar¬ 
bitrary  time  scale.  The  complexity  and  rapid  varia¬ 
tion  of  such  an  environment  necessitates  use  of  a 
fast  and  versatile  central-control  device,  a  role  well 
suited  to  digital  computers.  The  usual  system  will 
include  some  combination  of  sensors,  communica¬ 
tion,  control,  display,  and  effectors.  Although  many 
parts  of  such  a  system  pose  no  novel  management 
problems,  their  distinguishing  feature,  the  central 
digital  device,  frequently  presents  unusually  strict 
requirements  for  speed,  capacity,  reliability  and 
compatibility,  together  with  the  need  for  a  carefully 
designed  stored  program.  These  features,  partic¬ 
ularly  the  last,  have  implications  that  are  not  al¬ 
ways  foreseen  by  management.  An  attempt  is  made 
to  point  out  specific  hazards  common  to  most  real¬ 
time  digital  systems  and  to  show  a  few  ways  of  min¬ 
imizing  the  risks  associated  with  them. 

Humphrey85 

Humphrey,  W.  S.  “The  IBM  Large-Systems  Soft¬ 
ware  Development  Process:  Objectives  and 

Direction.”  IBM  Systems  J.  24, 2  (1985),  76-78. 

The  companion  paper  to  [Radica85]  and 
[Hoffnagel85]  that  introduces  and  motivates  the  ap¬ 
proaches  to  modeling  and  measuring  software  pro¬ 
duction  at  IBM  with  explicit  attention  to  process 
organization  and  management 


Huseth86 

Huseth,  S.,  and  D.  Vines.  “Describing  the  Software 
Process.”  Proc.  3rd.  Intern.  Software  Process 
Workshop.  IEEE  Computer  Society,  1986, 33-35. 

Briefly  describes  an  approach  to  the  use  of  object- 
oriented  and  frame-oriented  knowledge  specifica¬ 
tion  languages  in  developing  operational  models  of 
software  products  and  production  processes. 

Ives84 

Ives,  B.,  and  G.  P.  Learmonth.  “The  Information 
System  as  a  Competitive  Weapon.”  Comm.  ACM 
27, 12  (Dec.  1984),  1193-1201. 

Abstract:  With  the  help  of  information  system  tech¬ 
nology,  a  company  can  become  competitive  in  all 
phases  of  its  customer  relationships.  The  customer 
resource  life  cycle  model  makes  it  possible  for  such 
companies  to  determine  not  only  when  opportunities 
exist  for  strategic  applications,  but  also  what  spe¬ 
cific  applications  should  be  developed. 

Kedzlerskl84 

Kedzierski,  B.  I.  “Knowledge-Based  Project  Man¬ 
agement  and  Communication  Support  in  a  System 
Development  Environment.”  Proc.  4th.  Jerusalem 
Corf.  Info.  Techology.  ,  1984, 444-451. 

Describes  the  development  of  a  knowledge-based 
approach  to  representing  software  development  task 
chains  and  communications  between  coordinated 
development  agents.  A  prototype  processing  sup¬ 
port  environment  is  described,  as  is  its  suggested 
use. 

Kelly87 

Kelly,  J.  C.  “A  Comparison  of  Four  Design  Methods 
for  Real-Time  Systems.”  Proc.  9th.  Intern.  Conf. 
Software  Engineering.  IEEE  Computer  Society, 
1987,  238-252. 

Presents  an  elaborate  but  practical  scheme  for  ex¬ 
amining  and  comparing  different  tools/techniques 
for  designing  real-time  software  systems.  Such  a 
comparative  framework  and  analysis  of  various 
models  of  software  evolution  might  be  derived  from 
this  approach.  Alternatively,  van  den  Bosch82 
presents  a  different  approach  to  evaluating  software 
development  methodologies  (or  models)  through 
the  use  of  a  comparative  framework. 

Kldder8l 

Kidder,  T.  The  Soul  of  a  New  Machine.  New  Yoric: 
Atlantic  Monthly  Press,  1981. 

This  Pulitzer  Prize-winning  story  describes  the  de¬ 
velopment  life  cycle  of  a  new  computing  system 
(hardware  and  software)  by  a  major  computer  ven- 
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dor,  together  with  the  dilemmas,  opportunites,  and 
social  dynamics  that  shaped  its  development 
Strongly  recommended  as  one  of  the  few  descrip¬ 
tions  of  the  real  organizational  complexities  sur¬ 
rounding  the  development  of  computing  systems. 

Klng84 

King,  J.  L.,  and  K.  K.  Kraemer.  “Evolution  and  Or¬ 
ganizational  Information  Systems:  An  Assessment 
of  Nolan’s  Stage  Model.”  Comm.  ACM  27,  5  (May 
1984),  466-475. 

Abstract:  Richard  Nolan's  stage  model  is  the  best 
known  and  most  widely  cited  model  of  computing 
evolution  in  organizations.  The  model's  develop¬ 
ment  over  a  decade  demonstrates  its  own  evolution 
from  a  simple  theory,  based  on  the  factoring  of 
change  states  indicated  by  changes  in  computing 
budgets,  to  an  elaborate  account  of  the  character¬ 
istics  of  six  stages  of  computing  growth.  An  anal¬ 
ysis  of  the  model's  logical  and  empirical  structure 
reveals  a  number  of  problems  in  its  formulation  that 
help  to  account  for  the  fact  that  its  principal  tenets 
have  not  been  independently  validated.  The  model 
is  shown  to  be  an  "evolutionistic"  theory  within  the 
theories  of  evolution  in  the  social  sciences,  focusing 
on  assumed  directions  of  growth  and  an  implied  end 
state  toward  which  growth  proceeds,  and  suffering 
from  problems  inherent  in  such  theories.  Further 
research  based  on  an  "evolutionary"  view  of  com¬ 
puting  growth  is  suggested  as  a  means  of  improving 
theories  of  computing  in  organizations. 

Kllng80 

Kling,  R„  and  W.  Scacchi.  “Computing  as  Social 
Action:  The  Social  Dynamics  of  Computing  in  Com¬ 
plex  Organizations.”  Advances  in  Computers  19 
(1980),  249-327.  Academic  Press,  New  York. 

Provides  a  survey  of  the  organizational  dilemmas 
that  can  occur  during  the  development  and  use  of 
system  embedded  in  complex  organizational  set¬ 
tings.  Uses  a  case  study  of  the  life  cycle  of  one 
system  to  help  articulate  six  different  analytical 
perspectives  for  understanding  these  dilemmas  and 
their  interaction. 

Kllng82 

Kling,  R.,  and  W.  Scacchi.  “The  Web  of  Comput¬ 
ing:  Computer  Technology  as  Social  Organization." 
Advances  in  Computers  21  (1982),  1-90.  Academic 
Press,  New  York. 

Asserts  the  thesis  that  computing  systems  and  the 
ways  how  they  are  developed  and  used  are  in¬ 
separably  bound  to  the  settings  where  they  are  pro¬ 
duced  and  consumed.  This  work  employs  case 
studies  to  assert  the  primacy  of  understanding  the 
interrelationship  between  software  systems,  how 


they  are  produced,  and  the  settings  where  they  are 
produced  and  consumed  in  order  to  best  understand 
how  they  will  evolve. 

Lehman84a 

Lehman,  M.  M.,  V.  Stenning,  and  W.  Turski. 
“Another  Look  at  Software  Development 
Methodology.”  ACM  Software  Engineering  Notes 
9,  2  (April  1984),  21-37. 

Abstract:  Software  design  — from  ’topmost’  speci¬ 
fication  down  to  final  implementation  —  is  viewed 
as  a  chain  of  uniform  steps,  each  step  being  a  trans¬ 
formation  between  two  linguistic  levels.  A  canoni¬ 
cal  form  of  the  step  is  discussed  and  it  is  argued 
that  all  rational  design  activities  are  expressible  as 
a  combination  of  canonical  steps.  The  role  of  back¬ 
tracking  in  software  design  is  explained  and  a 
mechanism  for  introducing  changes,  both  in- 
digeneous  and  exogeneous,  is  proposed,  again  en¬ 
tirely  by  a  combination  of  canonical  steps.  The 
main  tenet  of  the  ’canonical  step  approach’  is  that  a 
design  step  contains  a  degree  of  unconstrained,  cre¬ 
ative  invention  and  a  calculable  part  which  is  the 
actual  transformation  effected. 

Lehman84b 

Lehman,  M.  M.  “A  Further  Model  of  Coherent  Pro¬ 
gramming  Processes.”  Proc.  Software  Process 
Workshop.  IEEE  Computer  Society,  1984, 27-33. 

Abstract:  Computer  applications  and  the  software 
that  implements  them  evolve  both  during  initial  de¬ 
velopment  and  under  subsequent  usage.  Current 
industrial  processes  to  achieve  such  evolution  are 
ad  hoc.  The  individual  activities  from  which  they 
are  constituted  do  not  have  a  common  theoretical 
base,  are  now  unified  by  a  single  conceptual 
framework  and  so  cannot  be  combined  into  a 
coherent  process.  Yet  the  latter  is  essential  for  the 
design  of  integrated  programming  support 
environments  and  it  is  widely  recognized  that  such 
support  is  necessary  for  the  creation  and  evolution 
(maintenance)  of  correct,  reliable,  cost-effective 
programs  in  a  manner  that  is  responsive  to  societal 
needs. 

Coherent  processes,  that  facilitate  evolution  of  a 
program  over  its  lifetime,  cannot  be  expected  to 
evolve  by  juxtaposition  of  established  practices,  ex¬ 
cept  over  many  generations  of  process  instances. 
The  rate  at  which  computerization  is  penetrating  all 
aspects  of  societal  activity  and  the  reliance  this  im¬ 
plies  on  correct  definition  and  operation  of  software 
systems,  suggest  that  mankind  cannot  wait  for  the 
'natural'  evolution  of  responsive  and  reliable  proc¬ 
esses.  Their  design  and  implementation  is  a  matter 
of  some  urgency. 

This  paper  outlines  the  first  steps  in  the  design  of 
coherent  programming  processes  by  decomposition 
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and  successive  refinement  of  a  model  of  program 
development  and  evolution  based  on  a  view  of  pro¬ 
gramming  as  a  transformation  process. 

Lehman85 

Lehman,  M.  M.,  and  L.  Belady.  Program  Evolution: 
Processes  of  Software  Change.  New  York:  Aca¬ 
demic  Press,  1985. 

Presents  a  collection  of  previously  published  papers 
that  identify  and  reiterate  the  "laws”  of  large  pro¬ 
gram  evolution  as  discovered  through  empirical  in¬ 
vestigations  at  IBM  and  elsewhere  over  the  preced¬ 
ing  10  year  period.  Unfortunately,  many  of  the 
papers  state  the  same  data  and  results,  and  therefore 
limit  the  impact  of  its  contribution. 

Lehman86a 

Lehman,  M.  M.  “Modes  of  Evolution.”  Proc.  3rd. 
Intern.  Software  Process  Workshop.  IEEE  Comput¬ 
er  Society,  1986, 29-32. 

Abstract:  Computer  applications  inevitably  evolve. 
The  very  activity  of  designing  and  creating  a 
mechanistic  system  to  automate  some  human  acti¬ 
vity  leads  to  a  change  of  perspective  and  an  in¬ 
crease  of  insight  into  the  problems  and  approaches 
to  its  solution.  Installation  and  operation  of  the 
completed  system  only  increases  and  broadens  this 
effect.  The  pressures  that  arise  from  the  changed 
perceptions,  newly  recognized  needs  and  opportu¬ 
nities  can  be  controlled  but  not  suppressed.  They 
lead  inevitably  to  demand  and.  hence,  authorization 
and  implementation  of  system  change.  And  the  key 
to  system  functional  and  quality  change  is  primarily 
through  modification  of  its  software.  Hence  the  un¬ 
ending  maintenance  burden,  the  continuing  process 
of  change  and  evolution  of  programs. 

Lehman86b 

Lehman,  M.  M.  “Approach  to  a  Disciplined  Devel¬ 
opment  Process:  The  ISTAR  Integrated  Project 
Support  Environment.”  ACM  Software  Engineering 
Notes  11, 4  (1986),  49-60. 

As  part  of  the  papers  presented  at  the  second  work¬ 
shop  on  software  process,  Lehman  describes  the  de¬ 
velopment  of  an  approach  and  an  environment  that 
support  the  production  of  large  software  systems  by 
teams  of  "sub-contractors"  working  on  the  project. 

Lehman87 

Lehman,  M.  M.  “Process  Models,  Process  Program¬ 
ming,  Programming  Support”  Proc.  9th.  Intern. 
Corf.  Software  Engineering.  IEEE  Computer  Soci¬ 
ety,  April  1987,  14-16. 

An  invited  paper  that  responds  to  and  debates  the 
proposal  by  Osterweil87  for  programming  the  soft¬ 


ware  process.  His  critique  cites  the  inherent  openess 
of  software  development  practices  and  the  limits  of 
being  able  to  characterize  such  practices  with  al¬ 
gorithmic  languages. 

Liker86 

Liker,  J.  K.,  and  W.  M.  Hancock.  “Organizational 
Systems  Barriers  to  Engineering  Effectiveness.” 
IEEE  Trans.  Engineering  Management  EM-33,  2 
(1986),  82-91. 

Identifies  a  number  of  organizational  conditions  that 
inhibit  or  reduce  the  productivity  and  effectiveness 
of  engineers  working  in  large  organizational  set¬ 
tings.  Although  not  specific  to  software  engineer¬ 
ing,  its  analysis  and  findings  are  easily  applied  to 
this  domain. 

MIL-STD-21 67 

Dept,  of  Defense.  DRAFT  Military  Standard:  De¬ 
fense  System  Software  Development  DOD- 
STD-2167A. 

The  current  draft  of  the  standard  guidelines  for  de¬ 
veloping  and  documenting  software  systems  by 
contractors  waking  for  the  U.S.  Department  of  De¬ 
fense. 

Narayanaswamy87 

Narayanaswamy,  K.,  and  W.  Scacchi.  “A  Database 
Foundation  to  Support  Software  System  Evolution.” 
J.  Sys.  and  Software  7, 1  (March  1987),  37-49. 

Abstract:  Most  software  engineering  researchers 
focus  on  supporting  the  maintenance  of  large-scale 
software  systems  to  tackle  problems  such  as  manag¬ 
ing  source  code  alterations  or  automating  the 
reconstruction  and  release  of  incrementally  altered 
systems  from  descriptions  of  their  configurations. 

In  this  paper,  we  take  the  view  that  information  per¬ 
taining  to  the  configurations  of  a  system  constitute 
a  basic  source  of  knowledge  about  the  system’s  de¬ 
sign  and  how  its  component  modules  fit  together. 
This  knowledge  is  articulated  by  the  use  of  a  special 
language  called  NuMIL,  which  captures  the  inter¬ 
dependencies  between  the  interfaces  of  components 
within  a  system.  We  then  use  a  relational  database 
system  to  store  the  descriptions.  This  enables  man¬ 
agement  of  the  description  of  large  software  config¬ 
urations  in  an  elegant  manner,  and  it  facilitates  the 
interactive  use  of  the  descriptions  in  analyzing  in¬ 
cremental  system  alterations  and  in  enhancing  the 
maintainer's  u/iderstanding  of  a  system. 

Neighbors84 

Neighbors,  J.  "The  Draco  Approach  to  Constructing 
Software  from  Reusable  Components.”  IEEE 
Trans.  Software  Eng.  SE-10,  5  (Sept.  1984), 
564-574. 
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Abstract:  This  paper  discusses  an  approach  called 
Draco  to  the  construction  of  software  systems  from 
reusable  software  parts.  In  particular  we  are  con¬ 
cerned  with  the  reuse  of  analysis  and  design  infor¬ 
mation  in  addition  to  programming  language  code. 
The  goal  of  the  work  on  Draco  has  been  to  increase 
increase  the  productivity  of  software  specialists  in 
the  construction  of  similar  systems.  The  particular 
approach  we  have  taken  is  to  organize  reusable 
software  components  by  problem  area  or  domain. 
Statements  of  programs  in  these  specialized 
domains  are  then  optimized  by  source-to-source 
program  transformations  and  refined  into  other 
domains.  The  problems  of  maintaining  the 
representational  consistency  of  the  developing  pro¬ 
gram  and  producing  efficient  practical  programs 
are  discussed.  Some  examples  from  a  prototype 
system  are  also  given. 

Nolan73 

Nolan,  R.  “Managing  the  Computer  Resource:  A 
Stage  Hypothesis.”  Comm.  ACM  16,  7  (July  1973), 
39-405. 

Abstract:  Based  on  the  study  of  expenditures  for 
data  processing,  a  descriptive  stage  hypothesis  is 
presented.  It  is  suggested  that  the  planning,  organ¬ 
izing,  and  controlling  activities  associated  with 
managing  the  computer  resource  will  change  in 
character  over  a  period  of  time,  and  will  evolve  in 
patterns  roughly  correlated  to  four  stages  of  the 
computer  budget:  Stage  I  (computer  acquisition). 
Stage  II  (intense  system  development).  Stage  III 
(proliferation  of  controls),  and  Stave  IV 
(user/service  orientation).  Each  stage  is  described 
and  related  to  individual  tasks  for  managing  the 
computer  resource. 

Osterweil87 

Osterweil,  L.  “Software  Processes  are  Software 
Too.”  Proc.  9th.  Intern.  Conf.  Software 
Engineering.  IEEE  Computer  Society,  April  1987, 
2-13. 

Describes  an  innovative  approach  to  developing  op¬ 
erational  programs  that  characterize  how  software 
development  activities  should  occur  and  how  tools 
can  be  used  to  support  these  activities. 

Polak86 

Polak,  W.  “Framework  for  a  Knowledge-Based  Pro¬ 
gramming  Environment.”  Workshop  on  Advanced 
Programming  Environments.  Springer-Verlag, 
1986. 

Describes  another  segment  of  the  knowledge-based 
approach  to  automating  software  production 
originally  presented  in  Balzer83b.  This  segment 
focuses  attention  to  a  specification  language  and  en¬ 


vironment  supporting  the  (semi-)automated  trans¬ 
formation  of  software  specifications  into  an  imple¬ 
mentation  language.  The  techniques  and 
mechanisms  employed  have  since  migrated  into  a 
commercial  product  called  REFINE. 

Potts84 

Proc.  Software  Process  Workshop,  C.  Potts,  ed.  Los 
Alamitos,  CA:  IEEE  Computer  Society,  1984. 

Proceedings  of  the  Erst  workshop  on  software  proc¬ 
ess  modeling  which  brought  attention  to  the  inade¬ 
quacies  of  traditional  life  cycle  models  as  well  as 
suggesting  some  alternative  ways  for  describing 
software  evolution. 

Radlce85 

Radice,  R.  A.,  N.  K.  Roth,  A.  L.  O’Hara,  Jr.,  and 
W.  A.  Ciarfella.  “A  Programming  Process 
Architecture.”  IBM  Systems  J.  24, 2  (1985),  79-90. 

Describes  experiences  with  the  development  and 
practice  of  an  approach  to  engineering  large  soft¬ 
ware  systems  at  IBM.  The-  PPA  is  a  framework  for 
describing  the  required  activities  for  an  operational 
process  for  developing  software  systems.  The  ar¬ 
chitecture  includes  process  management  tasks, 
mechanisms  for  analysis  and  development  of  the 
process,  and  product  quality  reviews.  It  also  re¬ 
quires  explicit  entry  criteria,  validation,  and  exit  cri¬ 
teria  for  each  task  in  the  software  production  proc¬ 
ess. 

Redwlne85 

Redwine,  S.,  and  W.  Riddle.  “Software  Technology 
Maturation."  Proc.  8th.  Intern.  Conf.  Software 
Engineering.  IEEE  Computer  Society,  1985, 
189-200. 

Abstract:  We  have  reviewed  the  growth  and 
propagation  of  a  variety  of  software  technologies  in 
an  attempt  to  discover  natural  characteristics  of  the 
process  as  well  as  principles  and  techniques  useful 
in  transitioning  modern  software  technology  into 
widespread  use.  What  we  have  looked  at  is  the 
technology  maturation  process,  the  process  by 
which  a  piece  of  technology  is  first  conceived,  then 
shaped  into  something  usable,  and  finally 
"marketed"  to  the  point  that  it  is  found  in  the  reper¬ 
toire  of  a  majority  of  professionals. 

A  major  interest  is  the  time  required  for  technology 
maturation  —  and  our  conclusion  is  that  technol¬ 
ogy  maturation  generally  takes  much  longer  than 
popularly  thought,  especially  for  major  technology 
areas.  But  our  prime  interest  is  in  determining 
what  actions,  if  any  can  accelerate  the  maturation 
of  technology,  in  particular  that  part  of  maturation 
that  has  to  do  with  transitioning  the  technology  into 
widespread  use.  Our  observations  concerning  mat- 
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uration  facilitators  and  inhibitors  arc  the  major 
subject  of  this  paper. 

Royce70 

Royce,  W.  W.  “Managing  the  Development  of 
Large  Software  Systems.”  Proc.  9th.  Intern.  Conf. 
Software  Engineering.  IEEE  Computer  Society, 
1987,  328-338.  Originally  published  in  Proc.  WES- 
CON,  1970. 

Often  cited  as  the  first  article  to  explicate  the  soft¬ 
ware  life  cycle  through  use  of  the  classic  waterfall 
chart  However,  it  wasn’t  until  Boehm76  that  the 
central  focus  of  software  engineering  was  explicitly 
linked  to  the  tools  and  techniques  required  to  ade¬ 
quately  support  software  life  cycle  engineering. 

Sathl85 

Sathi,  A.,  M.  S.  Fox,  and  M.  Greenberg. 
“Representation  of  Activity  Knowledge  for  Project 
Management”  IEEE  Trans.  Part.  Anal,  and  Mach. 
Intell.  P AMI-7, 5  (1985),  531-552. 

Describes  a  schematic  language  for  representing 
knowledge  about  complex  production  processes. 
Use  of  such  a  knowledge  representation  language 
and  its  associates  intelligent  system  (shell)  environ¬ 
ment  provides  an  advanced  basis  for  developing 
knowledge-based  models  of  software  products,  pro¬ 
duction  processes  and  their  interactions. 

Sathi86 

Sathi,  A.,  T.  Morton,  and  S.  Roth.  “Callisto:  An 
Intelligent  Project  Management  System.”  AI 
Magazine  7, 5  (1986),  34-52. 

The  follow-on  report  to  Sathi85  which  describes  the 
continuing  development  of  a  knowledge-based  ap¬ 
proach  to  representing  and  processing  complex  de¬ 
velopment  projects,  with  emphasis  on  emerging  is¬ 
sues  in  knowledge  representation. 

Scacchl84 

Scacchi,  W.  “Managing  Software  Engineering  Proj¬ 
ects:  A  Social  Analysis.”  IEEE  Trans.  Software 
Eng.  SE-10 , 1  (Jan.  1984),  49-59. 

Abstract:  Managing  software  engineering  projects 
requires  an  ability  to  comprehend  and  balance  the 
technological,  economic,  and  social  bases  through 
which  large  software  systems  are  developed.  It  re¬ 
quires  people  who  can  formulate  strategies  for  de¬ 
veloping  systems  in  the  presence  of  ill-defined  re¬ 
quirements,  new  computing  technologies,  and 
recurring  dilemmas  with  existing  computing  ar¬ 
rangements.  This  necessarily  assumes  skill  in  ac¬ 
quiring  adequate  computing  resources,  controlling 
projects,  coordinating  development  schedules,  and 
employing  and  directing  competent  staff.  It  also 


requires  people  who  can  organize  the  process  for 
developing  and  evolving  software  products  with  lo¬ 
cally  available  resources.  Managing  software  engi¬ 
neering  projects  is  as  much  a  job  of  social  inter¬ 
action  as  it  is  one  of  technical  direction.  This  paper 
examines  the  social  arrangements  that  a  software 
manager  must  deal  with  in  developing  and  using 
new  computing  systems,  evaluating  the  appropriate¬ 
ness  of  software  engineering  tools  or  techniques, 
directing  the  evolution  of  a  system  through  its  life 
cycle,  organizing  and  staffing  software  engineering 
projects,  and  assessing  the  distributed  costs  and 
benefits  of  local  software  engineering  practices. 
The  purpose  is  to  underscore  the  role  of  social 
analysis  of  software  engineering  practices  as  a  cor¬ 
nerstone  in  understanding  what  it  takes  to  produc¬ 
tively  manage  software  projects. 

Scacchi86a 

Scacchi,  W.  “Shaping  Software  Behemoths.”  UNIX 
Review  4, 10  (Oct.  1986),  46-55. 

Describes  in  an  accessible  manner  how  to  support 
the  life  cycle  engineering  of  large  software  systems 
through  the  use  of  tools  available  in  the  Unix 
operating  system  environment 

Scacchi86b 

Scacchi,  W.  and  J.  Babcock.  Understanding  Soft¬ 
ware  Technology  Transfer.  Internal  report.  Software 
Technology  Program,  Microelectronics  and  Comput¬ 
er  Technology  Corp.,  Austin,  Texas.  (Submitted  for 
publication). 

This  report  surveys  empirical  studies  of  software 
technology  transfer  and  transitions  experiences  and 
proposes  a  framework  for  understanding  how  differ¬ 
ent  software  technologies  should  be  developed  and 
packages  to  facilitate  their  transfer  to  other  settings. 

Scacchi86c 

Scacchi,  W.,  and  C.  M.  K.  Kintala.  Understanding 
Software  Productivity.  Internal  report.  Advanced 
Software  Concepts  Dept.,  AT&T  Bell  Laboratories, 
Murray  Hill,  N.  J.  (Submitted  for  publication). 

This  report  surveys  empirical  studies  of  software 
productivity  measurement  It  reports  that  there  are 
still  no  adequate  quantitative  measures  or  devices 
that  can  reliably  and  accurately  measure  software 
productivity.  As  an  alternative,  a  radical  approach 
to  understanding  what  affects  software  productivity 
is  proposed  that  utilizes  a  knowledge-based  ap¬ 
proach  to  modeling  and  simulating  software  prod¬ 
ucts,  production  processes,  and  production  settings 
as  well  as  their  interactions. 
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Scacchi87 

Scacchi,  W.  “The  System  Factory  Approach  to  Soft¬ 
ware  Engineering  Education.”  In  Educational  Is¬ 
sues  in  Software  Engineering,  R.  Fairley  and 
P.  Freeman,  eds.  New  York:  Springer-Verlag,  1987. 
(To  appear). 

This  chapter  describes  an  approach  to  engineering 
large  software  systems  in  a  graduate-level  software 
engineering  project  course.  The  report  describes 
some  of  the  software  engineering  tools,  techniques, 
and  project  management  strategies  that  have  been 
developed  over  the  history  of  the  SF  project,  as  well 
as  some  experiences  in  transferring  these  technol¬ 
ogies  to  other  organizational  settings. 

SEN82 

Special  Issue  on  Rapid  Prototyping.  ACM  Software 
Engineering  Notes  7, 5  (Dec.  1982). 

Presents  the  first  collection  of  full  papers  on  the 
subject  of  rapid  prototyping  of  software  systems 
originally  appearing  at  a  small  workshop  on  the 
same  topic.  Most  of  the  techniques  for  rapid 
prototyping  that  have  appeared  in  subsequent  litera¬ 
ture  and  research  investigations  further  explore 
work  appearing  in  this  collection. 

ThayerSi 

Thayer,  R.,  A.  Pyster,  and  R.  Wood.  “Major  Issues 
in  Software  Engineering  Project  Management.” 
IEEE  Trans.  Software  Eng.  SE-7, 4  (July  1981). 

Abstract:  Software  engineering  project  manage¬ 
ment  (SEPM)  has  been  the  focus  of  much  recent 
attention  because  of  the  enormous  penalties  in¬ 
curred  during  software  development  and  mainte¬ 
nance  resulting  from  poor  management.  To  date 
there  has  been  no  comprehensive  study  performed 
to  determine  the  most  significant  problems  of 
SEPM,  their  relative  importance,  or  the  research 
directions  necessary  to  solve  them.  We  conducted  a 
major  survey  of  individuals  from  all  areas  of  the 
computer  field  to  determine  the  general  consensus 
on  SEPM  problems.  Twenty  hypothesized  problems 
were  submitted  to  several  hundred  individuals  for 
their  opinions.  The  294  respondents  validated  most 
of  these  propositions.  None  of  the  propositions  was 
rejected  by  the  respondents  as  unimportant.  A  num¬ 
ber  of  research  directions  were  indicated  by  the 
respondents  which,  if  followed,  the  respondents  be¬ 
lieved  would  lead  to  solutions  for  these  problems. 

Tully84 

Tully,  C.  “Software  Development  Models.”  Proc. 
Software  Process  Workshop.  IEEE  Computer  Soci¬ 
ety,  1984,  37-44. 

This  paper  discusses  information  systems,  and  the 


system  development  process,  and  presents  a  number 
of  models  both  of  systems  and  of  system  devel¬ 
opment  It  also  presents  one  of  the  few  descriptions 
of  the  incremental  release  model  of  software  devel¬ 
opment  practiced  by  many  large  system  develop¬ 
ment  organizations. 

vandenBosch82 

van  den  Bosch,  F.,  J.  Ellis,  P.  Freeman,  L.  Johnson, 

C,  McClure  D.  Robinson,  W.  Scacchi,  B.  Scheft, 

A.  van  Staa,  and  L.  Tripp.  “Evaluating  the  Imple¬ 
mentation  of  Software  Development  Life  Cycle 

Methodologies.”  ACM  Software  Engineering  Notes 
7, 1  (Jan.  1982),  45-61. 

Abstract:  The  cost  of  developing,  maintaining  and 
enhancing  software  is  a  major  cost  factor  in  many 
projects.  The  inability  to  understand,  on  a  quanti¬ 
tative  basis,  what  factors  effect  this  process  severely 
limits  the  ability  of  an  organization  to  make 
changes  that  will  have  a  predictable  affect  on  im¬ 
proving  quality  and  productivity  of  software  prod¬ 
ucts. 

In  the  past  decade  most  software  organizations 
have  developed  a  life  cycle  approach  for  their  or¬ 
ganization.  The  approaches  which  describe  the  ac¬ 
tions  and  decisions  of  the  life  cycle  phases  have 
been  formalized  as  a  methodology.  Little  has  been 
done,  however,  to  define  a  basis  for  comparison  of 
these  methodologies  or  even  portions  of  these  meth¬ 
odologies.  Therefore,  there  is  little  data  to  guide 
management  to  direct  its  organization  on  what 
methodologies  should  be  used  in  the  life  cycle 
phases  in  order  to  enhance  performance  in  terms  of 
cost,  schedule,  and  technical  quality. 

This  is  a  proposal  for  a  project  to  develop  a  basis 
for  a  standard  quantitative  and  qualitative  analysis 
of  a  software  life  cycle  methodology.  The  goals  of 
this  project  are  to  define  a  process  by  which  an 
organization  can  monitor  its  life  cycle  and  develop 
this  process  to  produce  better  quality  software 
product  at  a  cheaper  and  more  competitive  price. 

In  addition,  this  project  will  provide  a  means  by 
which  methodologies  can  be  compared  across  or¬ 
ganizations  or  phases  of  the  software  development 
life  cycle.  This  would  be  invaluable  to  large  corpo¬ 
rations  that  have  many  different  software  develop¬ 
ment  organizations  and  large  agencies  who  have 
their  own  internal  software  development  agencies 
as  well  as  funding  other  organizations  for  large 
software  development  projects.  This  project  would 
provide  data  that  would  enable  these  corporations 
to  specify  methodologies  to  the  suborganizations  in 
order  to  have  a  positive  control  on  the  quality  and 
price  of  the  software  product  produced. 

This  project  consists  of  two  phases.  Both  phases 
will  be  discussed  by  this  proposal  but  the  actual 
funding  request  will  only  cover  the  pilot  phase.  The 
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pilot  phase  is  a  one-year  $100,000  project  to  vali¬ 
date  the  case  study  approach  to  this  problem  and  to 
redefine  the  type  of  questions  and  methods  by  which 
to  conduct  the  interviews  and  the  case  study  anal¬ 
ysis.  This  pilot  project  will  be  followed  by  a  three 
year  project  that  will  begin  by  studying  approxi¬ 
mately  seven  projects  and  will  be  the  start  of  estab¬ 
lishing  the  data  base  to  compare  methodologies 
across  organizations  and  phases  of  a  software  life 
cycle. 

Wlleden86 

Intern.  Workshop  on  Software  Process  and  Software 
Environments.  J.  Wileden  and  M.  Dowson,  eds. 
ACM  Software  Engineering  Notes  11,4  (1986). 

Proceedings  of  the  second  workshop  on  software 
process  modeling.  Includes  short  papers  that  con¬ 
tinue  debates  over  the  appropriateness  of  alternative 
models  of  software  evolution  started  in  the  first 
software  process  workshop. 

Wlrth71 

Wirth,  N.  “Program  Development  by  Stepwise 
Refinement”  Comm.  ACM  14,  4  (April  1971), 
221-227. 

Abstract:  The  creative  activity  of  programming  — 
to  be  distinguished  from  coding  —  is  usually  taught 
by  examples  serving  to  exhibit  certain  techniques. 

It  is  here  considered  as  a  sequence  of  design  deci¬ 
sions  concerning  the  decomposition  of  tasks  into 
subtasks  and  of  data  into  data  structures.  The  proc¬ 
ess  of  successive  refinement  of  specifications  is  il¬ 
lustrated  by  a  short  but  nontrivial  example,  from 
which  a  number  of  conclusions  are  drawn  regard¬ 
ing  the  art  and  the  instruction  of  programming. 

Wlseman85 

Wiseman,  C.  Strategy  and  Computers:  Information 
Systems  as  Competitive  Weapons.  New  York:  Dow 
Jones  Irwin,  1985. 

An  elaboration  of  some  of  the  ideas  presented  in 
Ives84  that  focus  attention  to  viewing  the  devel¬ 
opment  and  evolution  of  software  systems  as  corpo¬ 
rate  resources  whose  capabilities  create  or  inhibit 
competitive  opportunities  in  the  marketplace. 

Yacobellls84 

Yacobellis,  R.  H.  “Software  and  Development  Proc¬ 
ess  Quality  Metrics.”  Proc.  COMPSAC  84.  IEEE 
Computer  Society,  1984. 262-269. 

Describes  some  early  experiments  at  AT&T  Bell 
Laboratories  to  monitor  and  measure  software  pro¬ 
duction  processes  and  products.  Together  with  the 
studies  at  IBM  (cf.  Humphrey85),  this  suggests  the 
growing  importance  of  software  process  measure¬ 


ment  as  the  basis  for  studying  and  improving  large- 
scale  industrial  software  development  practices. 

Zave84 

Zave,  P.  “The  Operational  Versus  the  Conventional 
Approach  to  Software  Development”  Comm.  ACM 
27  (Feb.  1984),  104-118. 

Abstract:  The  conventional  approach  to  software 
development  is  being  challenged  by  new  ideas, 
many  of  which  can  be  organized  into  an  alternative 
decision  structure  called  the  "operational"  ap¬ 
proach.  The  operational  approach  is  explained  and 
compared  to  the  conventional  one. 
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